Hacker News new | more | comments | ask | show | jobs | submit login
The Quiet Crisis Unfolding in Software Development (medium.com)
263 points by Hates_ on May 28, 2016 | hide | past | web | favorite | 119 comments



> Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally.

This does not match my experience in ~10 years as a web developer. I see most of the technical debt coming from low performers, who take longer to deliver a poorer product. Most high-performers perform well precisely because they have mastered certain development processes, tools and good coding practices, which results in higher quality code. I'm thinking this must vary a lot according to your industry.


I hadn't seen that type of 'high' performer much for most of my career, but now I work at a place that appears to be plagued with them. I think some cultural practices foster that bad behavior, common in places that move fast.

One of them is to value support and firefighting very highly. The best firefighter is often one that is also the most familiar with the code, so it's common to see amazing firefighters that are also your arsonists! But when you don't track where the bugs come from well, and have little code ownership, whoever writes the most code writes the most bugs, does more firefighting later, learns more about the system, and distances themselves from the rest of your developers that actually want the system to work. This also increases the amount of tribal knowledge (as systems get quirky and badly documented), making it harder for anyone else to seem like a high performer, as to make any changes to anything that isn't new, you have to learn how the rest of the snakepit works. And as you learn how it works, it gets bigger, because the "high performers" are creating debt far faster than anyone else can learn it.

If bugs are treated seriously, tests are treated seriously, and how easy people join a team is considered an evaluation criteria for the existing team members, not the new ones, things are different.


> whoever writes the most code writes the most bugs

I'm experiencing this first-hand now. One colleague is writing lots of code very fast. Problem is, this code is far from perfect, and I spend a lot of time to understand it, and I find many bugs quite often. In the meantime while I'm reviewing, the guy writes even more code...


Hopefully you're not merging the feature branch until it passes code review. And if there are bugs, then you kick it back to him with all the comments you made.


In my experience, these types of employees are "too busy for that". And they typically have the political clout that they can continue to get away with it. I'm not saying it should be that way, and YMMV, but it's how I've typically seen it play out.


I definitely been at places that regard firefighters as heroes and people who want to build houses that don't burn down in the first place as trouble makers and pessimists. It is a terrible culture to have and sometimes it is difficult to get away from, because to admit that you've built a fragile system is to point the finger at someone for work they did months ago or to point the finger at yourself.


Very sharp summary. I definitely recognise this.


and then you end up with a company where one or two people are utterly indispensable.


Some organizations have that tendency no matter what is done. It's perceived as more efficient.


Nobody has any idea of how to place a value on any of those things, so you're just making it up so far as they are concerned.


Your development process is broken. How "high performer" can create technical debt in first place? I, personally, will not close ticket until it is well documented (i.e. code has comments, documentation is updated, ticket has resolution summary), and test cases are created (to be sure that nobody else will broke new code by incident), and code and test cases are properly peer reviewed by at least one member of the team (to allow information to spread across team), and all issues are addressed. Moreover, tickets are short, so they are easy to done and review.


I would disagree on this one as well, but it depends on the industry, and on the mindset: if you hire people that have only ever worked in go-go-ship-crap-but-ship environments you can't expect them to suddenly start thinking about unit tests, technical debt and good code hygiene, they need to be mentored to switch to that mindset (which is where the advice of mixing young/old talent comes in).

To give you an example I have been working for over 10 years at the same company and have to support today infrastructure code I wrote 6-7 years ago, and the previous company I worked at I worked for 5 years in a similar environment.

You can bet anything I write is VERY well unit tested and VERY easily understandable, and am extremely careful about technical debt and will push back quite strongly if asked to incur it "just for this ad-hoc fix/feature/deliverable", but that comes from a career spent with a certain mindset, when I was fresh out of university the words "unit tests" and "technical debt" were not part of my lexicon, I had a lot of algorithmic knowledge, but in a university environment you aren't drilled nearly as much as you should be on good code hygiene and practices.

If it was me in universities I would have a course in your 1st year where you have to develop some sort of application, and in your 5th year a follow-up course where you have to extend your original application and a classmate's in some significant way, that would drive the technical debt and writing code/docs/comment so you/others can understand later points very well.

And I would make it very clear over and over again that it's not the case that the less lines of code you write the faster it's executed, and that often the most compact solution ends up being the slower and less maintainable one.


That is a really good idea! Having people revisit old work is a powerful tool in learning. Definitely stealing this idea. :)


I've actually worked with that kind of "high performer". The guy was actually good, always on top of his game and aware of everything that was happening across product teams, but his haste to get things done quickly led to a lot of technical debt in our part of the product. He just checked things in continuously without waiting for a code review. Feature-wise he was adding a lot of value to the product, but always at the expense of code maintainability.

I was the one who couldn't sleep at night seeing all that debt and every now and then would clean things up. At least he would thank me for it :)


Developers come in many different forms, and I think this kind of "high performer" can be most valuable in an early-stage startup environment, where code quality hardly matters if product-market fit cannot be discovered before the runway ends.

I also suspect that many of these "high performers" are very aware of the technical debt they are adding, and simply prioritize shipping over anything else. To them, the mess is just a fact of software development, to be cleaned up only as can be justified by the needs of the business.

In general I don't actually agree with this view, but I also try not to dismiss it outright. (My counterargument usually involves the fact that technical debt will slow you down in the mid-to-long term, so if there is any expectation of keeping code around, it actually saves the business money to invest up front in code quality.)


Shit, that guy is me. I have brought back more or less dead projects with some good ideas and showcasing them.

OTOH, I am constantly worried I am too slow (the legend of the 10x developer does not help) and tend to omit test cases or leave code in that works but is not easy to read or understand.

At least I use every time I find to refactor code later, but we've had some bugs in UAT which shouldn't have been there.


If you refactor it later, I think it's fine. But this guy would keep cranking out code like mad and good luck keeping up with it. It was a bit insane at times.


Code reviews do not have to block checkins. See also "continuous integration". It's a way.


Part of our review process automatically compiles the new code, then runs unit and integration tests. The review is mostly for checking that new tests properly cover the change, the style and structure of the new code, and other problems that can't really be replaced by CI.


I'd think style and structure would be agreed on up front and possibly partially enforced by a formatting tool like Astyle. of course, prototyping might be something that can be varianced, so long as its agreed that the prototype will be discarded. But a given shop may not have the maturity for that. Shame, really.

Nobody ever wants to do it, but I've used a statement of work approach in the past.

I once used the wrong version of coding standards in a shop, and heard about it in a performance review. I'm in no way convinced this was inadvertent. My piece had negative defects - I found a dozen or so old crufty bugs in my testing. The rest of the team took months getting integration right.


We had a process: every code reviewed by at least one team member before checking in.


Perhaps, with the right kinds of expectations and code review processes, many of the "high performers" to which he refers end up becoming the "low performers" that you see as the cause of most technical debt. People who, in one environment, are able to ship buggy code quickly (and without much consideration) find themselves, in a different environment, spending abnormal amounts of time writing and reworking code in order to get it through a code review process.

He kind of mentions it, but in a very early-stage startup, the ability to deliver MVPs quickly (regardless of code quality) may be seen as a positive trait. Of course, even better is when you can ship quality code just as quickly, but such developers are probably the exception to the rule.


It's a question about the definition of a "high performer". From management's point of view, it's about implementing features - and it can happen that a person can implement a feature fast but mess up internal code quality. From a programmer's point of view, a "high perfomer" is someone who makes a change in software that is properly done on all levels - functional and non-functional.


When I read the article, this section annoyed me. You hit the nail on the head with this. I think the author should put this quote into the article to improve that section. Based on the rest of the article I think this is what he meant too.


Agreed, and it is not limited to web development. Effective developers seem to know what they are trying to do, have a plan for how to get there, and have a mental map of where they are, while poor developers are groping for a solution in a fog of confusion.

The author's claim is almost self-contradictory: if technical debt is bad, then anyone using it to create the illusion of being a high performer will end up hamstrung by his accumulated debt.


IME: The "effective" developer is never the one who has to clean up the accumulated debt though. They are pushed off to new projects before the warts start to show. It's everyone else that has to clean up after them.


Yep. They're moved on to the next project that needs their speed and expertise. Cleaning up the mess is usually left to those who don't pump out new lines of code quite as fast.


Good point - I have seen that myself.


> These leaders should also be publicly recognized as such. Promote them to the job they’re already doing. This formalization makes it easier for them to assist other developers without hard feelings — it’s now part of their official job description! — and provides them with recognition which increases morale. Without that official recognition, providing assistance can often feel like little more than an unwelcome burden. Don’t let that happen to your employees.

Piggy-backing off of this astute suggestion, I'd also like to say that it signals to other developers in the org that the org appreciates and rewards people stepping up. This can be hugely important for retaining talent -- it's the difference between whether an employee thinks they have somewhere to go in their current org, or if they have to leave to step up.


I'd add one thing to that list: be wary of genius developers.

I currently work on a project where one of the most senior guys was an incredibly smart person. He wrote extremely complex parts of the code that "just work". The trouble is he's now gone from the team, and no one understands why certain things are written the way they are, and people are afraid to touch them.

Despite being really smart, this person was not very good at communicating. Your typical shy and introverted little genius who does it all on his own. When asked to explain things, he would just say "trust me, it has to be this way", but wouldn't really explain why he made certain decisions or wrote the code in certain ways.

So now we're in a situation where there are parts of the code we can't touch because "he said it had to be this way". Great. I call it personality-oriented engineering. A total failure.

This person got to a higher position because management only looked at how smart he was and how he was able to deliver complex solutions that would impress everyone. They failed to realize how bad he was at leaving a legacy of maintainable code that can be moved forward.


Yes, be wary of hiring geniuses if you have poor management.

Why do we expect that someone who is fantastic at twiddling bits, to also be good at documentation? It's like saying to a Program Manager "great, you specified how it has to work, so now just take a few hours and code everything up". Or "how come you weren't coding as you went along?"

The solution is to pair these 'unbalanced' developers with people who are good in other areas. Where was the technical writer who was talking with him on a near daily basis? Or the SDET who worked with him to make sure the important aspects of his design were codified into tests?

You can have 10 reasonable devs spend a year getting something to work and have it be reasonably maintainable/documented/tested/etc. (If you actually even have 10 reasonable devs in the first place). Or you can have 1 'genius' do something fantastic in 6 months with minimal support and hope that your other devs can fill in the gaps.

Remember, you don't go to war with the army you want--you can't say "this person would be great if only they __". You can only work with them or not work with them. If they are genuinely doing what they think is best for the company, then I recommend you figure out how to work with them. Their challenge is to figure out how to be effective in an organization that doesn't understand, and your challenge is to figure out how to make an organization that can understand.


> genius developer

Who writes unmaintainable, unreadable code? Not my definition of genius at all. I worked with one genius in my 20 year career. He was a marine biologist and knew more about computers than me. He was scary smart and all the advice I had from other people about working with him was - he thinks in steps 1, 6 and 20. You need to get him to explain how he got from 1 to 6, and then how he got from 6 to 20. Often this would take weeks to get out of him, but the though had just popped into his head (often while working on something else.) Very interesting man. One of his quirks was the he had no idea what time of day it was. We had to tell him to go home or eat his lunch, else he'd just think it was perpetually "about half nine"


I highly disagree with this.

There is such a thing as domain expertise. For example, machine learning, compiler design, graphics programming, etc. If you are say, a web developer these people might seem like geniuses to you, and no, you wont' be able to pick up and understand their code. This isn't because it's not documented well enough, or that it's not written well, it's because you lack the domain knowledge to understand it. For example, I've written code that you absolutely will not understand without weeks or more of study in the domain. The code is documented, and has links to science papers that you need to read to understand it. But know that you may need to spend months to learn enough to really know it.

It's not the responsibility of the domain expert to teach you an entire domain. So yes, they may just tell you to trust them instead of telling you to go study some volume of domain work. It would be better if they did the latter, but I suspect that many here would still complain with that answer.


Agreed. Background / culture makes a big difference on how well devs can understand each other's code.

I still wish more of my teammates (past & present) wrote more comments (as in "statement of purpose", at the top of a chunk, not just "this part is complicated", in the middle here and there) in their code, though. :-)

Anecdata: As somebody who did actual paid work in an interpreted / dynamic language in the late 80s during and just after college, I seem to see people who have only been through the C ... Java regime struggling with more "modern" (? alternate, anyway) dynamic / functional scripting type languages. It's just not something they are familiar with (intuitive = familiar).

Not that CSU did a great job teaching FP in the 80s, but we at least got to play with original flavor Lisp a few times...


I understand what you're saying but it's not the case in my specific situation. We're all developers within the same field of expertise and know what we're working with. Some of the code does require clever solutions, but we try to make it as understandable as possible and document the obscure things. This guy however would just disregard all that, implement clever but convoluted solutions to problems and all he would offer as an explanation was "trust me guys, this is how it's done." And that would be all.


Seconded. The most important thing for me, when writing code, is whether or not I (or someone else) will be able to read it in 6 months. The second most important thing is whether I'll be able to throw this away and replace it with something else, which perhaps counterintuitively means I need to spend more time ensuring the code I'm writing doesn't wrap tendrils of interdependencies into the rest of the codebase. An important part of that is ensuring that any major interfaces/APIs (both internal and external) are simple, predictable, and well-documented.

Even following those two rules alone, you can avoid building these complex, black-box solutions that nobody is willing to touch.


>there are parts of the code we can't touch because "he said it had to be this way".

You know what? That just means you haven't shrugged his influence off. He's still casting that long shadow.

When our local genius left, I felt lost but eventually stepped up, went through his code line by line documenting it, wrote enough tests so that I could be sure that I wouldn't introduce bugs while rewriting his code to make it readable for me. I learned quite a bit from that.


Seconded. If this guy really wrote good stuff then this is a great learning opportunity. If you have some way to contact him even moreso. He may not be the type of person who can easily summarize or teach someone new to the codebase, but I bet if you read through it, got to know the problem and had specific questions about details of his approach, he would be more than able to discuss it with you. Often this kind of personality enjoys sharing their thoughts, they just don't enjoy spending lots of time getting someone up to speed from ground zero. But putting in the hours to grok the code might put you in a good position to have productive conversations.


I personally shrug it off, but I'm one of the newest guys in the team so I don't have a lot of clout to push for changes yet. Everyone else though seems to be caught into some sort of mysticism around the genius guy. Even our architect and our manager have this attitude of "we can't change this; it might look strange and we don't know why it's there, but he said that was how it had to be." It's very upsetting.


Good for you. I didn't want to pick on you or your colleges so much, I just think your local "genius" has weaknesses like everybody, but in reality your company is at fault.

They should not mystify him, they should have made sure he shares knowledge with others and brings other up to speed. And as he is gone, they should make sure the code is refactored to suit the documentation level and code style the remaining devs are used to.


> be wary of genius developers.

Is not it a subset of "high performers"? The dirty secret of all such "genius developers" is exactly this - they all simply traded rigour and quality for a speedy spitting out of a "good enough" code.

For the outsider this pace may look like magic, for someone who is left to maintain the mess it looks, well, like a mess.


I think code review can help here. Even genius developers' code should be reviewed and understood by other developers. This can help reduce the bus factor and level up other team members. The genius developer will learn to "dumb down" (hopefully in a good way) their code to reduce overhead to their productivity from long code reviews with many questions.


Can't you just pull that part out into a test driver, and "treat it as a hostile object" ( a hostile witness is one who only answers yes or no questions )?

If I was his manager, "it just has to be this way" wouldn't work, but obviously different strokes.


"If design and code reviews aren’t highly interactive with lots of questions and recommendations, your employees aren’t taking them seriously or they’re too shy to speak up. Very often one or two developers are interested in them but without obvious interest and input from the rest of the team even interested developers will tend to severely curtail their questions and recommendations."

This drives me nuts, it manifests itself in some many different ways: * The "immediate" thumbs up on a PR * The PR that sits and languishes forever * The chat room of silence when someone asks an architectural/design question

It can get really frustrating. Still no clue of a good way to fix it since the problem stems from a long built team culture that needs to change.


IANAM so grain of salt.

> The "immediate" thumbs up on a PR

This one bugs me too. Really? On a PR with 400 delta lines, you didn't need clarification on anything? I don't know what action to take here.

> The PR that sits and languishes forever

Get your team to agree to an PR review SLA on the order of a day or two. "Enforce" the SLA -- how you do this depends on your team and the situation, but it can help to just remind people that they collectively agreed to the SLA.

Suggest reviewing PRs with the same cadence as checking email (~1-2x per day).

> The chat room of silence when someone asks an architectural/design question

Identify one or more "natural leaders" as mentioned in the article, and encourage them to check on the chat room periodically (email cadence?) to route questions to the most likely person. They should know who that person is because they're generally well-connected, and mentioning them by name creates social pressure for that person to respond.


On the flip side - to properly review a 400 line pr would take hours unless you were involved in discussions with the developer along the way like let's say he's making changes to the api while you're working on the consuming client.

I typically ask for the devs to push their code into the repo incrementally as long as the change doesn't break anything. That way you have manageable prs and if there's a need to go back to the previous version you have smaller deltas to deal with as well.


>I typically ask for the devs to push their code into the repo incrementally

That's fine provided each of those PRs gets reviewed and merged almost immediately but if you don't do that then either the developer has to create a separate branch for each incremental improvement (horrible) or let them mount up into a monster pull request (also horrible).

Some changes also kind of need to be large in order to not break anything (deep architectural changes).


Yea speed is key with incremental prs. Which is on me most of the time as a lead SA on the project. I encourage the devs to slack me directly or drop an @here note in one of the relevant channels. I do the same when submitting prs myself too.


A 1 line change can be just as dangerous as 400 line one. I'd argue that alot of the so called "small" changes are just as tricky to review as a big one simply because the context of what is being changed isn't really a part of the PR. (i.e the reviewer has to trace through the framing code to really understand what's going on.) The difficult part is keeping enough context floating to know when a deeper dive is required.


> On a PR with 400 delta lines, you didn't need clarification on anything? I don't know what action to take here.

My thinking is that, if I approved a PR you wrote and it had a bug, I was as much to blame for the bug as you. That should help with frivolous approvals, but I've never had much of a problem with them, so take it with a grain of salt.


You can also (soft) require people not to take on any new issues if there are any PRs outstanding.


The bigger problem I have with code review in general is that they are never about finding bugs. They almost always devolve into style concerns. Because style is an easy, bike shed, thing. Finding bugs means knowing the context, and thinking about the code.

The best code review flow I've seen is where you put in a review, assign it to a specific person or two, and then merge that code.

What my current company has is the godawful github PR synchronous flow that everyone seems to love. This allows a few individuals to hold your commits hostage unless you bend over and implement their pet style. It pisses me off on a daily basis, and I'll probably quit in another month or two.


We leave style to the tools. We use pep8 and that's it. The commit won't even work unless we're pep8 compliant, and if the tool says you're ok, you're ok. I can't even remember the last time I saw a style-related comment on a PR.


So it's not a problem with code review. It's problem with the way people review the code. In my team we do discuss style here and there to keep it at least semi consistent, but we agreed to mostly check for possible bugs and/or maintainability. This means that a code review might actually be feature review where one person looks what had to be done, how was it done and maybe something is missing. So far it was pretty effective for us.


Having a team style guide helps a lot with that tendency: you get the argument over with once, team-wide, then write down the conclusion. So during each code review it's just a question of: does this match the style guide, yes or no? (Or you can enforce it automatically with tools like ESLint). And then the discussion can focus much more deeply on other aspects of the code.


The best piece I've read on the subject; I agree with everything he has written and it's the stuff I've told management at many companies I've been at. I've yet to see any of them listen to me though; usually, if they don't do things the way outlined here, they just don't get it and the offered reasons will not resonate.


I agree, I could have written the same essay myself!

Except for the last point:

> but a nice pair of jeans and any decent shirt with a collar should do just fine.

Why should there be such a requirement? Why can't people wear shorts and/or t-shirts if they want? Of course there should be some requirement (like having some kind of clothes on) but otherwise I don't think any code is necessary as long as the team is comfortable.


First impressions. It's a subjective and sometimes faulty human practice of making judgements about the trustworthiness of people without knowing much about them. The benefit is that it requires less energy than actually getting to know the judged.


I understanding where you are coming from; I thought the same when I was a few years younger and was wearing t-shirts with texts like "not even Norton can protect you", "every time you download music, God kills a kitten" and "I read your e-mail". And while those are a lot of fun, it's not fun to explain to customers and have to say: "Don't mind them, they are just our developers..."


If I were to meet a customer, I'd probably skip the t-shirt and shorts that day, no dress code required. But that depends on the customer, of course - with some customers, wearing a tie and suit as a developer may raise eyebrows.


I get what you say, but doesn't the fact that you'd wear something different, were you to meet customers, indicate that it might not be the best work attire? While I agree a suit should not be required, I'd say if you'd have to change your cloths to meet a client, it's probably not suited for work.


> I'd say if you'd have to change your cloths to meet a client, it's probably not suited for work.

Why? With clients you wear more formal clothes for PR purposes. It shouldn't be necessary on most dev teams (in my experience).


I'd disagree. When I am slumming it at home, I wear the most comfortable pair of trousers I have. If I'd receive a call to have a beer with pals, I'd still change.

I think the same applies in the given example: the in-group knows the guy in the shorts and T-shirt is a nice dude who helps others and is super-professional about quality. The customer, as an outsider, just sees someone who's underdressed.


Question: Why are your customers seeing your developers?


The idea that developers should be hidden from customers, like lepers, is offensive to me as a developer.


I dunno, I am certainly not hidden from our customers; I interact with them directly, every day, over email, phone and screen-shares. But other than rare on-site visits and conferences, I don't see them face-to-face, so it doesn't much matter what type of shirt, or even any shirt at all, that I'm wearing.


Compartmentalizing workers from each other and from customers is a means of control. Specifically management is trying to make sure that their developers do not get exposure to internal or external groups that may try to hire them away. Or give them a job if they get fired or laid off.

Consider

Case A: Customer knows you well understands you are competent. If you want to leave or are laid off that customer might eityher hire you or know someone who does. Or at least will give you a solid reference.

Compare with.

Case B: Customers and others only know you through your boss.


That's probably relevant only to the companies that work in the same field as their customers. But there's another issue that applies to all: it makes that layer of managers relevant. If they'd let the developers talk to the customers directly, they wouldn't be needed anymore.


Multiple scenarios that I've encountered.

1) company that creates custom modules for firms coal software; it always involves meeting the customer. 2) Open office layouts where customers are given a tour of the Office.


At one place, we kept suits / formal office clothes in the closet for those times. No need to make it a regular thing.

On the other hand, at one place I worked it would have been illegal for the customer to interact with us in our office space, but we still had to wear formal office clothing.


How often so you have customers walking through where the developers work? I imagine this differs a lot per company (from every day to almost never).

Not to mention having to hear the same old jokes every time the customers go look at the monkeys.


I agree, I think this was a great write up.

Unfortunately, the company I currently work for has begun adopting and exhibits many of the behaviours and poor choices this article warns against. And is actually on a path to employ more of them, quelling any objection that might come up.

Sorry, it's just frustrating watching a company make such consistent poor choices.


The open space bit keep nagging at me. I've liked and hated it in equal parts, but the truth is that as soon as I was able to spend time working from home I stopped wanting to go to the office daily, period. I'm so much more productive when not sharing a table with a half dozen folk.


After working primarily remote (in the office one day a week) for six months, it's been extremely hard to get back in the grind of having to go to the office again. I have a mostly private corner office, so it's not some open-office Lord of the Flies situation, but still, I'm so much more productive in a space that I control fully, where there are no casual distractions, and I don't have my blood-pressure and pissiness levels cranked up by having to commute in and deal with traffic in the morning.

If anything, I communicate more when I'm at home than when I'm in the office... Excessively verbal people don't seem to be able to handle it well, however, from what I've seen.


Same here. IME it also makes you like your team more.

I once sat next to a software developer who always listened to talk shows/lectures while developing. I then resented having to maintain or add features to code he touched.

When I started working from home, I can just tell myself that he's focused and trying his best (which may have always been the case). It still looks like code developed by someone who is distracted but I no longer know that for a fact.


I also agree with this. I am currently in one of those shared hubs (S&C Sydney). My team is fantastic but it is ridiculously distracting have a bunch of flat desks just up against each other in rows, looking into the face of someone right in front of you. Having some stranger on the desk next door talking about crap that has nothing even to do without my company. It's like open plan but made even worse. I find I am working from home about 3 days a week and slack* seems to help the communications a lot. Going in a few days is great for the moral and needed for shared design but takes a lot away in terms of productivity. (* slack, LOL, the corporate world discovered the same IRC I have raving on about for 20 years+ LOL)


Open floor plans are ~80% of the time about cutting cost but only about ~20% of the time is this actually admitted by executives. There are plenty of problems at my current job but being cattle caged in an open floor plan is not one of them. Almost 100% of the time my introverted self performs an order of magnitude better within the sweet sweet sanctuary of my door-locking, fully-enclosed, window-with-some-mountains-in-the-background office. To the point of feeling golden handcuffed by it. I'm sure I'm not a minority in this. I wonder why more companies don't pay the extra, yet in many cases workable, expense.


Which is stupid. You pay me a fuckton of money, do you want me to spend time chitchatting about trivial stuff with the rest of my colleagues, or implementing features you need to release? What is really more expensive, the floor space or the lost productivity? (double-bonus points when you work in a "low cost" geography but still use open-plan office because US uses it and this is the corporate standard)


I like this article on a whole, but I do have a comment on this quote

> Optimizing for the common scenario means giving developers primary ownership of portions of the code base and not allowing other developers to change that code without approval from the primary owner. This results in higher productivity since any given developer is more likely to be familiar with the code in which they will typically be working.

I have worked with someone overly protective of the code sector he wrote, but it has caused problems since I would like to fix some bugs in the API signature of that code, but the developer has stonewalled me in the past & raised a ruckus when I filed PRs to fix some of it. If it is something that affects how other people interface with a feature, IMO it is not a good thing to necessarily designate a primary owner & mandate all changes go through him/her. Granted, some of the problem is that the other developer probably was in the wrong being obstinate, but you work with the cards you're given.


Mozilla addresses this, in part, by having one "module owner" but also multiple "module peers". All code changes in a module should be reviewed by the owner or (more usually) a peer. Having multiple peers reduces module owners' review burden, reduces bus factor, and gives "reviewees" someone they can appeal to if their PR is rejected. Linux has a similar organization with Linus' "lieutenants".


It makes sense to have centrality of vision for how code should be laid out. This is software architecture (as skill and role, not title though!). And as people have a limited focus span, it makes sense to segment - by business topic, by API, etc. But of course fiefdoms emerge.

In some ways, it might then almost be better to not have that person contribute to same codebase: to avoid ego pissing contests and to keep the opposing pressures in balance. The pressures being: delivering features on time on one hand, and keeping things clean and orderly on the other hand. Often, if the architect codes then they can't see their own mistakes, but have 20/20 vision of others' grubby flaws, and hence gain subconscious animosity towards external contributions.

That being said, an architect who does not code is even worse! This is where we get ivory tower Architect-as-title, and even less gets done. I wonder what the optimal middle ground is.


Perhaps the middle ground is a software architect who codes, yet has high emotional intelligence and acts as a servant leader. Someone who honestly wants to help their teammates, and doesn't feel "better than them".

Perhaps they lay out a system design as a suggestion on a wiki and ask their teammates including themselves to collaborate on it until everyone's content with it.

Then perhaps they code a particular layer primarily and are humble and open to criticisms and mistakes they make in their own coding. They understand that they and others are not perfect, nor is the code they or others produce.

That and good relationships and communication with the product, design, management, qa, and support teams are what I feel would define a valuable "Software Architect".


> Despite there not being a single shred of scientific evidence in favor of open office workspaces being a good idea and overwhelming evidence in favor of them being counterproductive for most software developers, this unfortunate fad is currently widespread. Software developers need private workspaces to ply their trade.

Yep. Perhaps this could be softened a bit to say there are different sorts of devs, some seem to work OK in open plan offices and some need private work space. But personally I'm in the latter group. My company moved to open office space and I've come to not even think of the office as a place where I get real work done. Thankfully they allow me to work from home as well, that's one of the main things I'll be looking for in future employers. I have to admit I can produce a feeling of moderately intense anger by just thinking of the Yahoo executive banning work from home because she believed that everyone's job involved frequent impromptu hallway chats or whatever the fuck.


"Don’t have Stupid Dress Codes" is then followed by a dress code:

"For some of them that’s jeans and a basic collared shirt and for others it’s business casual."

Which for the author's arbitrary reasons leaves out jeans and a t-shirt - although this guy makes some good points, this one is a bust.


yeah, that comment really seemed to show how out-of-touch the author really is. I haven't worked in a place that required a collared shirt in more than a decade. The last few interviews I've had, the interviewer wore a t-shirt and jeans.


He works in a consulting company in Texas. You need to project a certain level of professionalism to make your customers feel comfortable. Sometimes looking weird can be positive, e.g. for designers, but it can be a distraction.


He said stupid dress code and then comes up with a reasonable one.


I don't see how it's reasonable. If you're going to demand a collared shirt, you may as well demand a suit.


"Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally"

This is repeated over and over in almost every management book; managers are starting to believe it. In the book "The Phoenix Project", Brett, the most technical guy, was the high performer to fix almost everything. The moral in that story was that Brett was also the Fire Starter. No, management need to feel high performers below them actually belong there. Unfortunately technical skills fade and once good managers become bad and incompetent. Worse, most technical managers were never technical. Just this week I had to put out a fire most certainly not caused by me or my code. I inherited a mess from outsourced workers. Any requests to improve the code base were met with disapproval. Some of our custom code interfaces with an external system that has an API. When we upgraded to the latest version of the external system; it became more strict on what it allowed. To help with the migration, management paid many thousands to have three "experts" on the system come in and help make transition to the new version go smoothly. I was not on the migration project. However, when sh@t hit the fan I was called in. Testing was poor and they went live. The three experts could not find the cause of major problems and certainly no one else on the team was willing to step up. I had to spend the entire week becoming an expert on the external system and quickly fix the problem. Yes, I am a high performer and I did not cause the fire. It is because I roll up my sleeves, get to work and never give up. I'm sorry if that scares some management. That they actually need some people.


excellent article, it is especially interesting the advice on being liberal with promotions and technical career track, given that in several companies I've worked for when you get to a certain level (principal/staff/lead/... whatever) getting promoted further is an exercise in frustration, because either there are only X slots (we can't have more than X fellow positions in the company) or it becomes a matter of having to play politics, or you end up in companies where the technical ladder has a (sometimes low) glass ceiling.

I would've added a paragraph on stack ranking and curve ranking in general, which although obviously extremely detrimental to morale and retention, still unfortunately rears its head at times, and one about how to handle layoffs/restructurings as those are not easy to do well.


Sensible advice, but I didn't see anything about a quiet crisis.


I took from it that the quiet crisis is an increase over the last 10 to 15 years of the opposite of what he recommends: rewarding high performers without making sure they are not taking shortcuts, not allowing people time to clean up technical debt, treating developers as interchangeable so they don't feel code ownership, not recognizing natural leaders with promotions and raises, using misleading metrics that encourage gaming the system, allowing developers to be unnecessarily interrupted during their workday, open floor plans that produce a distracting environment, not allowing time for exploratory side projects, limiting mobility within a company so a developer unhappy in a group can't move to another, turning down small requests like a new keyboard, waiting too long to do a employee review, treating management as a step up from software developer (as being better than,) placing too much emphasis on having young energetic employees and not appreciating the experience and wisdom that older employees bring to the group, arbitrary corporate rules like overly conservative dress codes.


This is a problem that affects more than just programmers. Management is seen more these days as a generic function performed by a special (upper) class of people and less as a function performed by high performers in their respective fields.

This happened in medical care (the rise of non-medical medical management), academia (c.f. the rise of administrative positions in university), charter schools and industry, too.

The problems he complains about are consequences of this more general shift - when managers do not understand what it is they manage, they seek out brain dead metrics to measure performance, which, in the absence of understanding the field, severely damages performance.

Programmers have more in common with welders, doctors, nurses, lawyers, teachers, etc. than they seem to think.


The crisis is that software shops are ignoring the basics and pushing "fadish" solutions:

  "... I’ve noticed a quiet crisis unfolding in software development leading to low quality applications, unhappy employees and unhappy users. Silver bullet solutions keep creeping into our awareness (Scrum, anyone?) and predictably keep letting us down.
  This is almost entirely the fault poor management — or perhaps it should be called fad management."


Nothing has changed since Fred Brooks wrote The Mythical Man-Month.

Fads will always exist as long as someone benefits from selling the fad. And there is always someone selling shovels in a gold rush.


This implies that they weren't before. I'd argue it's more that trends were slower to change in the past, for better and worse.


That was my take as well. I found myself nodding along but expecting him to transition at some point to revealing the quiet crisis in detail. Ultimately just a problem with the structure of the piece, and not the content.


I think the crisis is bigger than software development. It's evident at all levels of society.

There is a real lack of leadership in the world.

Everybody is so averse to risk and afraid to follow their own beliefs that they end up doing what everybody else is doing. That is not what leaders do. This is how we end up with scrum. It's also how we end up with partisan politics, a dozen sequels of the same movie, and nickelback.


There seems to be a lack of emphasis on 'shipping working software' in this list. As a developer, that is what I ultimately want to be judged on. Nothing else. And too many managers judge developers by how closely they adhere to their silver bullet development process which they read in a random website.

It seems like the only ways to do this are

1) Create a startup, ship something awesome, have a great exit 2) Work for wall street, in a position where your success is judged by how much money you make, which directly drives your bonus.


>There seems to be a lack of emphasis on 'shipping working software' in this list. As a developer, that is what I ultimately want to be judged on.

I'm not sure I do. Shipping software in a mess of technical debt is much slower than greenfield development or development on a well architected product.

I'd ultimately want to be judged by an architect who reads all pull requests and understands at a deep level how all of the code fits together.


What's also missing is how to actually make extensible designs. I have seen very, very few designs that were able to accommodate unforeseen changes, and none that resulted from good coding practices.

Most often I've observed that the more process and organization surrounds a development effort, the more likely that effort will outright fail (sometimes by never getting completed, more often by never actually fulfilling the function that was designed for, then abandoned. The difference is that the second kind is very much declared complete).

Recently a thorough focus on code hygiene (unit tests taken to a ridiculous levels, for instance) is one more warning sign that it's time to find something else to do. The biggest warning signs are project teams way bigger than they need to be, but ... Code hygiene nazis merely join the documentation madness of a few years back, PMs should control everything because Steve Jobs was a successful asshole, we need 5 design docs before even knowing what the problem is, ...


Good management needs to tend to the longer term health of their team and organization. A rockstar developer shipping working software is good, but when that person quits or no one understands their code or they're a jerk causing other team members to be unhappy, that is a problem.


If you pick your utility functions poorly, people start adapting to them with unintended consequences:

- Burndown charts: Burn lots of tasks fast, even if you are creating more work in the process.

- IBM once rated employees based on added lines of code. The result? An explosion of code. Even code that wasn't strictly necessary.

- Stack ranking: punish the lowest 20%, reward the top 20%. Sounds reasonable at first, but what happens when employees adapt to it? People stop hiring strong candidates. So over time, when people leave, their replacements get worse over time creating a downwards spiral of worsening talent.


This is a good analysis, but it needs a silly name to be accepted as a new management trend.


Software Development Management for Dummies


I like that :-) To rearrange the letters slightly for a better acronym; "Managing Software Development for Dummies", or MSDD ;-)


This resonates with my experience. I agree that it requires a weird name to start productive conversations :)


Lots of good points here. Limit Interruptions and Prefer Private Workspaces are big ones imo. If only companies realized that those 2 things can increase production and output 10 fold. Sure open offices are cheaper but you are paying for it in other ways.


There are some fine insights but generally it's the old view of managers vs programmers as passive workers. For example, the advice for managers to encourage programmers to do refactoring as part of normal (business-oriented) tasks is skewed. It's programmers who know the field and they should have some power to give refactoring tasks the same value as business-oriented ones. They should be partners.

My view is also probably skewed compared to what a typical "software development" company does, but I don't believe that Google or YC startups do this kind of management.


This all seems highly sensible advice to me!


The real crisis is that people are NOT willing to create new software. And I don't mean the "bag of libraries" that much of software seems to be.


"at a minimum each developer should have a cubicle with high cube walls and a small entrance"

Sounds more like a prison cell. How about daylight or a window?


Great article. I thought the title was pretty misleading though. My suggestion: Advice for managing succesful teams.


Quietly unfolding? This has been going on for decades. In fact I think it's prevalence is less these days. Not that I think the avg quality is constantly improving.


I think right now it got out of hand. With a lowered entry barrier to development, now a regular code base feels like reading http://thedailywtf.com/

There's now a social network for developer rants: https://www.devrant.io


I guess its a subjective thing, depending on where you have worked and with whom. I'm pretty picky where I work these days, so maybe I haven't witnessed what you are talking about.

However I think these days, at the higher end of the spectrum, the general awareness of good programming practices is better than it was 25 years ago. Back then, unit testing frameworks weren't a thing, I didn't see any CI, often code repositories were zips on a file share..., patterns were barely a thing....


It's almost as if the crisis is all these people that think this or that little item, feature, observation, insight, idea, etc. is soooo terribly important.


I was agreeing with all his points until he decided to ban ripped jeans !!


this is the best work-related article/essay i've ever read since i started in this field in the 90s. (except for the collared shirt part lol that's odd.)




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: