Speaking of peter principle, has anyone felt like the peter principle works at the organizational level too? Every company feels dysfunctional because well-managed companies tend to succeed in the marketplace and keep growing headcount until they cannot be managed any more. This seems even more inevitable than at the individual level because growth is much more inevitable for a successful company than promotion is for a successful employee.

Not sure I agree with the last sentence. Depends a lot on what pool you are talking about when you say successful employee. All successful employees in all companies? A successful employee in a large one?

Apart from that, talking of the Peter Principle on an organizational level, I think there are more ways to remedy the problem.
A change in management philosophy when hitting the ceiling can have a better impact on overall performance, if chosen carefully, and therefore seems more feasible to me than expecting an individual to be able to put himself in a position/mindset to excel at a task that isn't tailored towards his/her strengths that the person has honed for the past x years.

Companies stall at different sizes, so you cannot say style A will take you to 10k employees no problem. It depends so much on other factors, too. By that I am thinking of industry-related factors, typical mentality in that field/sector/country, etc.

Having said all that, I am in no way qualified to make statements or even directly exposed to those dynamics, just talking about my gut-feeling.

1) I could see myself asking a couple of those questions. "What would happen if you ate a tomato right now" would probably the first thing that I'd be curious about.
2) I'm very happy that all of my allergies mysteriously vanished (had a ton as a kid, none now)
3) My dad is very allergic to apples but somehow the ones from our garden don't affect him at all. It's really strange because he's also allergic to other "bio apples" so it's not some "toxins from mass market apples" conspiracy. Truly baffling tbh (maybe some supersized placebo effect but I doubt it since he's very aware of the situation)
---

@candybar: I think it can't apply because I'm currently rereading Neuromancer and your idea would invalidate the megacorps

---
It actually shows you a decent bit about the person you are about to hire. I like it as the first question. Let them write it however they want. Will they TDD it without being told to do so? Will the code be hacked together or take into account future changes (DRY but also YAGNI can be discussed here)? What if I wat to print "LolPwned" instead of "FizzBuzz", what if I want to change %5 to %32 etc.
[the actual solving of the problem is fairly irrelevant it's more of a how do they get there, how do they think about it. If they can't solve it...obviously a nice idiot filter]

Are you saying promotion is inevitable for a successful employee in some organizations? This is not true outside of entry-level at any organization. Whereas successful companies by definition will have opportunities to expand.

If you overcome the ceiling by changing something, that wasn't your ceiling in the first place and you will continue to grow until you hit a real ceiling that you can't or won't overcome. This means most companies end up getting stuck at a point where they are poorly managed. The point of the generalized peter principle is that this kind of maneuvering doesn't matter - the only preconditions are that success be rewarded with more responsibility. And successful companies are rewarded by being given more money to expand.

As an aside, organizations are much harder to change than individuals - google institutional inertia.

Good post and basically agree with your points. The hiring process is pretty bad really. Situations like example 1 happen more than we would like them to. Since in example 1 the code is written in C for an embedded application (?) I guess your options are limited to perhaps just introducing C++. Just curious.

Some would say that this is a pretty apt description of the situation at the biggest software company in the world.

Introducing C++ in the existing code base of hunderedish files won't help any future dev's work. I think it would make a bad base even worse.

But if management insists I will do so. In fact, that would be in line with other decisions made so far but going into more detail here would bust this discussion.

Also, previous devs seem to have tried to do so already. Result being, as far as I can tell, that it is 99% C code in .cpp files. Alrighty then.

TIL "individual contributors" is a thing.

Good point.
My mindset just can't grasp the being stuck in a role thing and not doing anything about it. So I obviously do not even take that into account.

Without making me read through all that, is that observation based on all aspects of inertia (mindset, culture, processes etc) or just certain ones?
I found many people to be incredibly stuck in their way of doing things.

Here's a question to those of you who actually work with TDD.

I want to start building a small game that has been floating around in my head for about 5ish years. And since I haven't had any projects whatsoever based on TDD, I thought that would be a good opportunity to practice it.
Instinctively, I want to flesh it out bottom-up as I am not 100% sure which avenues I want to use for user interaction just yet but do know fairly well how I want the core engine to look like. UI could be in part browser based, other parts application driven. All I do know is that I will need extensive APIs.

So, the question to the TDD experts is this: Would you think a bottom-up (or inside-out or whatever it is called) is a good way to go or are there compelling reasons to rather take the top-down (outside-in / enter equivalent terminologies here) be more feasible?

Do keep in mind that I have effectively no hands on experience with TDD - if that is a factor in the decision.

And as a bonus question (potentially based on the direction) which books or resources in general would you recommend to read for this?

Rewrite the software time .

I would think working back end to front end is less likely to result in a discovery that drastically affects the rest of code or drives you in a direction you are unhappy with to support a front end decision.

I have a sneaking suspicion that the ratio of development teams who actually use TDD versus those who have used it a little, or want to use it, or used it for a while then gave up – is very very high. I base this on the immaturity of all the tools out there, and the lack of answers for very simple problems that we seem to run into – like incredible slowness of running the tests.

But I could be very very wrong. Obviously I know open source projects have to use it. But those are usually frameworks or one-feature components, with little UI or concrete feature–level requirements. I wonder how many other projects - where the end result is a fully functional app with complex, constantly changing UI/UX - actually use it.

I don't really get the need for testing most of the stuff that a lot of TDD enthusiasts will test.

For example, a year+ ago I did a testing course with thoughtbot (basically the best rails consulting shop in the world, and big proponents of TDD) hoping to learn more about testing. We were using TDD to write a basic todo list app or some ****. We wanted to update the signed in user's last activity or something. We ended up with this

So it's a very basic method that as far as I can tell has 0 edge cases. We got the behavior to pass on the feature test we were writing (end to end test we wrote first), but still had to write a test for this very basic method. I still don't get it, and will never write a test for this method.

Using rspec, the test would look something like this:

I don't even think this test would pass, because Time.now would be different by a small fraction of time. In comes a tool like https://github.com/travisjeffery/timecop

Then someone can get on my case for not mocking or stubbing or some **** to make the unit test faster. My solution is to not write this test. Don't get me started on how much time I've wasted debugging tools like capybara, especially on heavy JS applications.

I have slipped on testing on my latest project... but it hasn't hurt me at all in terms of development time (has definitely made it way faster). I'm also a lone wolf building a big project. I am very fast at this point at diagnosing errors and not making simple ones.

I have about 50 unit tests which cover all of the vital functionality. Something needs to work and has edge cases? I'm gonna write tests. TDD or tests after, doesn't matter to me, just needs to work. I can't imagine the complexity of trying to get a ton of people to TDD or CI a huge code base.

Seems like 2-8 developers would be a good case for TDD... but I really don't know. My plan is to finish up with this beta I'm working on and start adding some tests before refactoring. Nothing crazy though.


Meh, my random thoughts. I'm still relatively new to the world of development, so take it with a grain of salt.

"But it works! Therefore, we should be able to build upon that."™

Thanks for the feedback. That's exactly what I am thinking so far.
Not sure if there be dragons with that approach I cannot see until it is too late.

That's interesting. I have no realistic idea of the ratios other than that what I've seen in my professional career. And no one there has been doing it consistently.
Might be a result of the fields I have worked in?

i've been employed in the industry for 8 years and i get imposter syndrome all the time. i can spend like 4 hours on a problem that ends up being a 3 line fix and i'm thinking like, 'wow, I'm really a senior programmer?'

Standard.

I have 2.5 years experience (after 4 years of poker) and was promoted to Engineer Sr. right as I was leaving to accept a job at another big company as a Sr. Engineer. No matter how hard I try, in seven years I'm still not going to be able to provide the "Minimum of 10 years experience engineering" under the "Required Skills" of the job description.

There are far more jobs than qualified people, so lots of opportunities to succeed at a higher level. Sort of like being an officer during WW2.

You get over your impostor syndrome pretty quick the first time you work along actual impostors.

I haven't looked for a job for around 10 years, what are the good sites to look these days?

What I find most disturbing is that, while I'd love to telecommute (even part-time), I've been unable to find any of those jobs/contracts.
One would think programming lends itself to it.

Wrt job boards: Most suck and primarily serve as DB filler gateways for recruiters.
On the bright side, there are excellent recruiters out there. Eg. I've landed almost every contract during my time in Europe through one specific recruiter.
Haven't found "the one" in Australia, yet. Sucks.

I thought job boards are the domain of recruiter spam or companies with high attrition rates because they only hire unicorns.

Perhaps there are thousands of applicants with PhD's in deep learning from a top 10 school with 7 1/2 years of Swift experience and a love for learning x86 / Haskell that are interested in building the next-generation enterprise PHP w/ hand-coded JavaScript and HTML3, 4, 5 website.

Most people I know that telecommute worked in person at first. While the job lends itself relatively well to it, its still requires some additional skills/work ethic and its nice to work in person first to ensure it will work out.