The care and feeding of software engineers (or, why engineers are grumpy)
Not too long ago, Jenna Bilotta wrote an excellent article called, How designers and engineers can play nice[1], in which she talks about ways for designers and engineers to work more productively. Having faced similar challenges working with designers (and also working with engineers, when I was on the UI side), I appreciate the pragmatic approach she suggests. It always helps to respect the other role’s process and understand their thinking when working together.
One of her points for engineers was not to say “no” so quickly. That one stuck with me for a while and swam around in my head. My first reaction was, “but you don’t understand why we say no!” And a million other defensive thoughts soon joined in the party. She is right, of course. We do say “no” very quickly, not just to designs, but to everything. That led me into thinking about the psychology of software engineers and what makes us the way we are.
Our reputation
Cards on the table, software engineers generally have a reputation for being arrogant, disagreeable, and moody. We also have a reputation for saying “no”, for debating pedantic details, and thinking we know how to do everyone’s job better than they can. In general, this reputation is deserved. That’s exactly what we do, day in, day out, as we intermix writing code with checking in on Twitter and Hacker News.
(Side note: There are some who will say that’s not true of all engineers, and you’re right. There is a small subset of engineers for which some or all of these are untrue. Before scrolling to the bottom and leaving comments telling me how dumb this article is, please keep reading.)
Reputations aren’t randomly given out, they are earned based on experience. What makes the reputation disturbing to me is that I know many software engineers personally, and they are generally a fun-loving, agreeable (if not opinionated), and entertaining bunch. They’re the ones you want to hang out with after work and catch up with on the weekend. So why is it that in the presence of work, a different personality shows up?
Creators, not builders
I have a theory. That theory is that software engineers see themselves very differently than those with whom they work. I’ve come to this conclusion after over a decade in the software industry working at companies large and small. Companies (product managers, designers, other managers) tend to look at software engineers as builders. It’s the job of the product manager to dream up what to build, the job of the designer to make it aesthetically pleasing, and the job of the engineer to build what they came up with. Basically, engineers are looked at as the short-order cooks of the industry.
This is something that my very first manager warned me about. When the first company I worked at went under, he and I had a very frank discussion about my career. While we didn’t always get along, he gave me this excellent piece of advice (paraphrasing):
Nicholas, you’re worth more than your code. Whatever your next gig is, make sure that you’re not a short-order cook. Don’t accept a job where you’re told exactly what to build and how to build it. You need to work somewhere that appreciates your insights into the product as well as your ability to build it.
He was absolutely correct. There are a lot of companies that want short-order cooks, they want implementers and builders to march to a specific beat and stay in line. In fact, I’d say most companies want that, large and small. I can’t tell you how many startups contact me offering equity in exchange for building the founder’s vision. The implication: we already have all of this figured out, we just need someone to build it.
And here’s the real crux of the problem: software engineers aren’t builders. Software engineers are creators. Building is what you do when you buy a piece of furniture from Ikea and get it home. The instructions are laid out and if you go step by step, you’ll get that comically small table you wanted. Creating is a different process, it’s birthing something without direction or instruction. It’s starting with a blank canvas and painting a masterpiece. Software engineers don’t get into coding because they want someone to tell them what to do, they get into it because they discovered they could create something useful. Every single software engineer fell in love with coding because she made a small, useful program early on and was hooked.
In the triumvirate of software, product managers, designers, and software engineers, only the engineers are expected to turn off their creative minds and just produce. Software engineers aren’t dumb, they see this happening, and resentment starts to build (no pun intended). The engineers want to be part of that creative process and are denied. Thus you end up with the typical software engineer personality accented by grumpiness.
Wait, what’s the problem?
Product managers are interesting people. Their ideas and capacity for understanding markets are impressive. They also have a tendency to believe that their ideas are fully-formed when, in fact, there are holes so large that trains could fit through. I say this with love, as several good friends are product managers, and you all know I’ve said this to your face at one time or another. This is absolutely not a criticism of product managers, it’s just in their nature. Their job is a creative one, and ideas do not emerge fully-formed. And that’s part of what makes software engineers grumpy.
Both engineers and product managers tend to think, incorrectly, that product specifications or requirements are equivalent to the furniture manual from Ikea. In reality, these documents rarely contain enough information to build an actual thing. They’re usually just the starting point. And that presents a unique problem to the engineer.
To understand the problem, consider the job of building a house. Someone has decided they want to build a house on a specific plot of land. The house is to be two stories and have a garage. There’s even a rough sketch of the front of the house scribbled down on a napkin. That person comes to you with this information and the napkin and says, “this is enough for you to start building, right?” Are you able to start building?
Logically, you can’t start building the house at that point. You don’t know the square footage. You don’t have floor plans. You don’t know what sort of codes the city requires for new houses. There’s literally not enough information for you to even start digging up dirt. At this point, you’d tell your customer that they are crazy and need to figure out exactly what they want. Now imagine you can’t do that, because there’s a deadline that someone set and you’re responsible for meeting.
“Well,” your customer tells you, “why don’t you just start building, and I’ll get you the details as they become available. That way, we’re not wasting any time.”
You know that there’s not enough information for you to start building, and further questioning the customer won’t yield any additional information right now. Yet, you have a deadline to meet and so you really can’t afford to sit around and wait for more information. What do you do? You start making assumptions.
The old adage, “when you assume, you make an ass of u and me,” is about as true as can be. Assumptions are dangerous and often wrong. Yet without making some assumptions, the project can’t move forward. So that’s what you do. You start by assuming that what you already know is true, the house will have two floors and a garage. The garage, should it be attached or detached? How big should it be? Well, let’s keep things simple and say it’s detached and houses a single car. That means you can start on the garage as a standalone structure on the side and then, when there are more details about the house, you can continue right next to the garage.
After a week of working on the garage, your customer emerges with more details. In fact, the house has to be three floors (phew, good thing you didn’t start there) and will have eight bathrooms. There’s no further information about the garage, but the house is going to be painted blue. You then logically assume that the detached garage should also be painted blue and so that’s where you spend time next.
A few days later, the garage is almost done. You feel pretty happy about the quality because you went on so little information. You’re now ready to start on the house when your customer comes back with more details. The garage actually needs to fit two cars and should not be detached. Your heart sinks, since you had created something nice and now it needs to be bulldozed to make way for the “real” thing. What’s worse, you now have less time to complete the entire project, which only increases the grumpiness level.
If this analogy seems crazy to you, you’ve probably never worked as a software engineer. This is our reality every single day. We try to keep projects moving by using our creative facilities only to find that we, in fact, can’t read anyone’s mind and therefore guess incorrectly as to what exactly it is that we’re building. And yet, if we don’t do that, we would sit there idle, as no one likes the waterfall process of software development.
In almost every other industry where things are built, it is expected that all requirements and details are agreed upon and finalized before building commences. Except in software. In software there’s “not enough time” to gather all the requirements ahead of time. The importance of moving quickly is hammered into us from day one. And so engineers learn to fill in the gaps left by product managers just to keep the project going. Product managers, of course, also have the reputation for changing their minds frequently, which means engineers assumptions are often invalidated partway through the process.
Is it any wonder that software engineers tend to burn out quickly and change jobs frequently?
Number one priorities
The enemy of any creator is context switching. Once you get into a deeply creative mode, “the flow” as some call it, being disturbed to shift focus to something else completely interrupts the process. Yes, writing code is a creative process. It’s both logical and creative at the same time. We aren’t simply writing code, we are crafting it.
There seems to be a thought amongst people who manage engineers’ time that it’s easy to shift from one task to the next. After all, as some people have told me, effort is effort. You just direct it where it needs to go like a cannon and fire. Of course, that’s not at all true. If you spend a lot of time on one task and then are asked to drop it to work on something else, you can’t very easily go back to the first task and pick up where you left off. There is a re-acclimation period once you return to make sure you understand all of the context, this is the cost of context switching. Even if the new task takes only a few minutes to complete, it’s enough to interrupt the flow and therefore make an engineer less productive.
This is one of the top things that make engineers grumpy: constantly shifting priorities. If something is a number one priority on one day and something else is a number one priority on the next day, that means inevitable context switches must occur. Creative types don’t like being interrupted until they’re finished, which is why engineers are happy to continue coding until the wee hours of the morning just to complete what they’ve been working on. Interrupting the flow makes us less productive.
True priorities aren’t transient, they are static. The frequency with which people above us change their minds is incredibly frustrating for software engineers. We frequently stand ready to march into battle and just want a direction to march in. But if you tell us one day that we’re building a house and the next day that we’re building a car, you should expect some dissension in the ranks.
The engineer flaw
Software engineers are put into a difficult position every day, but we are not victims even though those of us who are more melodramatic tend to act that way. Part of our grumpiness actually comes from within, with something that for some reason is deeply ingrained in the majority of software engineers. We have a tragic flaw and that flaw is that we overestimate our knowledge and abilities.
This flaw presents itself in a number of ways. The most frequent is in time estimates. Almost every engineer I know chronically underestimates how long it will take to complete a task or series of tasks. Only the very best are able to give and meet accurate time estimates while the rest are sometimes off by a factor of two or more. The problem is that, as creative people, software engineers fail to anticipate the problems they will encounter.
Even though many engineers will complain that product managers change their minds, almost none will account for that in their time estimates. No time is put in for meetings to go over requirements and make changes. Bugs? Our code is perfect and never has bugs, so we don’t need to worry about that (after all, QA will catch anything we somehow missed, right?). Some of the other engineers who we rely on will be out? That’s okay, someone else will pick up the slack.
All of those add up to missed deadlines very quickly, but none do as much harm as the number one reason things don’t get completed on time: not factoring in time for learning. This goes directly back to our flaw. We think we already know how to complete the tasks we’re given yet very frequently they are things we’ve never done before. The time estimates reflect a state of perfect knowledge, where you have the Ikea manual and plow forward. In reality, many tasks are asking us to do things we’ve not done before.
Engineers who studied computer science in college are given a false sense of security in their classes. They come out thinking they understand software and the software development process when, in fact, they know next to nothing. I was absolutely that arrogant college graduate at my first job, telling everyone they were doing it wrong. Only years later did I figure out I knew nothing.
Computer science programs aren’t about preparing you for the tasks you’ll face in industry. They’re about giving you conceptual knowledge of a wide range of topics so that you’re not blindsided when you find them in your work. You learn about variables, functions, and objects, because those are things you’ll encounter all the time. You learn about databases and queries though the normal forms you learn are practically useless. You spend an inordinate amount of time on sorting algorithms and data structures, all of which are abstracted away from you when writing code professionally. In short, computer science programs review solutions to problems that you’ll never need to solve on your own when coding professionally. If I need to sort something these days, I call the sort()
method. If I need a queue or a linked list, I use the implementation that’s native to the language I’m using. These are all solved problems.
So we come out of college thinking we know how to do everything when in fact we only know how to do what has already been done. And to that end, we know a very small amount of what has already been done. Yet we act like we know it all, and assuming perfect knowledge, give estimates that are way too short because we don’t take into account time for learning.
Part of the problem is also our fragile egos. We get afraid that if we give an estimate that is “too long”, that people will think less of us. “Good engineers” should be able to work faster, they say, and so we acquiesce. I’ve always been amazed when an initial estimate is given on a project and a non-engineer comes back and says that it’s too long. First off, as I already mentioned, it’s probably actually too short due to our flaw. Second, how can a non-engineer know how long something will take to be built? And that leads to another issue.
I used to code
There are few phrases that anger software engineers more than, “I used to code.” Whether it comes from a product manager, designer, or upper management, using this phrase in addition to a rationalization about why an engineer is wrong leads to nothing but disdain. If I were to ask LeBron James how much time he needs to prepare for a game, I’m sure he’d be amused if I disagreed because I played basketball in high school. Software engineers get the equivalent all the time.
Here are some common fallacies uttered by non-engineers in my presence:
- I don’t understand why this is such a big deal. Isn’t it just a few lines of code? (Technically, everything is a few lines of code. That doesn’t make it easy or simple.)
- {insert name here} says it can be done in a couple of days. (That’s because {insert name here} already has perfect knowledge of the solution. I don’t, I need to learn it first.)
- What can we do to make this go faster? Do you need more engineers? (Throwing more engineers at a problem frequently makes it worse. The only way to get something built faster is to build a smaller thing.)
The worst thing you can do for engineers is tell them you used to code. Note that this is very different from actually having been a professional software engineer. An engineer turned product manager has some automatic credibility for a finite number of years after switching jobs (usually around 5, longer than that and everything has completely changed). But those who’ve never developed software professionally are better served to keep their coding hobby in their back pocket rather than using it as justification for anything in a business.
(To be fair, designers are also subject to this problem. Everyone is a visual design hobbyist because we all like pretty things. That doesn’t make everyone qualified to design something.)
More cooks
Software engineers also constantly face the problem of having too many cooks in the kitchen. Because we are underestimating how long it will take to complete tasks, most software is late. That goes for companies large and small, products that you know and love, they all fall into this category. Being late makes management unhappy, to which they usually decide the problem is too few engineers. We will just hire more engineers, they say, and that will make everything better.
In some cases, adding a few more engineers will work. In most cases, adding more engineers only makes the problem worse. It is hard enough getting creative people to coordinate with each other, it gets more difficult as soon as you start adding more people in. Engineers are not allowed to have idle time as a general rule. If management realizes that engineers are idle they tend to create work for them.
This happened to me in an almost comical way several years ago. We were designing the new Yahoo homepage, rebuilding it from scratch, with just a small group of people. It was actually an ideal situation where the few of us were able to focus on the base architecture upon which the page should be built. We had it all designed and were ready to start prototyping when all of a sudden we were given eight engineers. Our marching orders? Those engineers need to start writing code for the new home page right away. Quite a conundrum because the architecture didn’t exist. But the engineers couldn’t be idle, they were assigned to the project and needed to start doing something. It’s a classic chicken and egg problem.
In an ideal world, we would have built at least a prototype of the architecture and then received additional engineers to help build. In this situation, however, we were stuck. What I ended up doing was to use an existing architecture that we had from another project and create a thin façade that made it appear as if our actual architecture existed. The engineers were able to stop their work and we were able to work on building the actual architecture at the same time. This was a horrible solution to horrible problem and it ended up biting us later on because engineers reached the edges of the façade where new architecture functionality would eventually be but didn’t yet exist. I finally had to tell my manager at one point that unless he gave us time to build out the actual architecture the house of cards we had built would come crumbling down.
Having too many engineers on a project is a serious problem. Adding more engineers assumes that there are parallel tasks to be completed, but in reality, the number of parallel tasks on any one project is small and finite. When there are more engineers than can be used, engineering time ends up going away from developing and towards planning, synchronization, and coordination. To go back to my earlier metaphor, you can’t build the second floor until the first floor has been built. Many tasks on a software project are actually sequential, so adding more engineers doesn’t speed things up. Or as one of my former colleagues used to always say, I don’t care how many women you give me, it still takes nine months to make baby.
Real grumpiness
So, without enough information, changing requirements, not enough knowledge to do the job, and people constantly second guessing us, we trudge into work every day. Being creative people, we put up with all of this because we know that one day people will use our work. That’s really what drives software engineers more than anything else: the idea that people we don’t even know will be affected by our work. Whether you’re working on a web site visited by millions each day or you’re working on a point-of-sale system for restaurants, the knowledge that we’re affecting people’s lives is a powerful driver.
I can't state this enough: Programmers don't burn out on hard work, they burn out on change-with-the-wind directives and not 'shipping'.
When there are delays due to people changing their minds, we get very grumpy. Insanely grumpy. Our goal of getting our work in front of people has been deferred, and that’s demoralizing. Amazingly, software engineers are typically not perfectionists. We are usually okay with getting something good out there rather than getting something great out there. We like building small things to ship quickly and then later combining them into a big thing. Why? Because that’s how we get our work out to people.
Now, we all know delays are part of software as much as anything else. Engineers will work like crazy if their time estimate was off to try and make it work. Engineers don’t hate hard work or long hours; we hate when it doesn’t pay off.
What thanks?
As a software engineer, our jobs operate on very different timelines than others. It’s typically not a designer or product manager that’s woken up in the middle of the night because something is broken in production (though, I have known PMs who wanted to be called when that happened). I was once about to leave my place with a date when the office called because of a production issue. She sat and waited patiently for an hour while I tried frantically to fix the issue before she ultimately took off (I couldn’t blame her), leaving me to my work and my coworkers in IRC sharing my misery.
Yet, you’ll rarely find software engineers complaining about long hours or being woken up because of a production issue. The software is our baby, and we like to care for it as such. That means if it needs feeding in the middle of the night, we do it. If it needs extra care over the weekend, we do that too, all with a smile because our creation is growing.
Engineers are especially happy when they’re able to check in the last bits of code for a task. I’ve never seen engineers so jovial as when they send out an email saying a task is complete and ready for review. Yet that mood is quickly dashed when in the next ten minutes, bugs start getting filed against their newly-created baby.
Imagine that for a second, if you will. You’ve worked for a day or a week or many weeks on something and checked it in. You’re proud because you accomplished the task, probably learning to do something you didn’t know before. All you really want is to take a moment to sit back and admire your work for a bit. Maybe have someone say, “good job.” And what response do we get? Bugs. Something isn’t working, something else is out of place, and so on. Our good mood is destroyed as we rush into fixit mode.
Why we say “no”
Given everything I’ve mentioned, here are the common reasons why engineers say no (or otherwise seem grumpy):
- The request is coming late during development and there’s not enough time to fit in before the deadline.
- The request invalidates one or more assumptions that were made early on in the process to get the project moving.
- The request is a reversal of previous requirements.
- The request otherwise increases the amount of work that has to get done before the deadline.
- We are so burned out that any request seems like a ton of extra work and we just don’t want to deal with it.
Keep in mind all of these except for the last one have to do with the engineer meeting a deadline to get the project out the door. We want the tasks to be completed, and the only way that happens is if the tasks don’t change while we’re working on them. When they do change, that’s when we get really grumpy and that’s when the “no” comes flying out of our mouths before you even finish your sentence.
Care and feeding
So how do you deal with these grumpy necessities to your business? Review for a moment the things that drive engineers:
- Being creative
- Solving problems
- People using our work
Note what’s missing from that list. Money. Throwing money at engineers rarely satisfies them. It sounds cliche, but it’s really not about the money for engineers. Money allows them to have fun, but what really interests us is coding and creating. When we can do that in a healthy environment, we’ll remain happy for a very long time.
So how do you create a healthy environment for engineers?
Work cross-functionally
Software engineers are creative, just like product managers and designers, and so you should work to include them in the creative process. Engineers are tremendous assets in brainstorming sessions and when reviewing initial designs. Give every engineer the opportunity to meet with the ideation team and work directly with them (not necessarily all at the same time). In short, inject the engineer into the creative process earlier. No engineer likes getting specs and designs thrown over the wall without understanding them.
Engineers are highly logical, so being in these early meetings to understand where requirements come from can go a long way towards avoiding problems down the line. When engineers feel like builders, they question and that slows down the process. When engineers are co-creators, there are fewer questions and therefore fewer delays later in the process.
What’s more, engineers are frequently way ahead in terms of knowledge of what is possible. If you consider front end engineers, we have knowledge about what browsers are capable of long before product managers and designers do. When we share that knowledge, we actually give everyone new ideas for how to build products because of what is possible. Imagine if you were trying to create a photo sharing site and didn’t know that you can now drag and drop files from the desktop into the browser to upload?[2] How would that affect the product design?
So, invite engineers into the creative process early on. Let them give you feedback and provide information about what is possible. The less it feels like we’re being dictated to, the more likely we are to listen and happily go about our jobs. And that only really happens if we feel like we contributed to the creation of this thing.
Make a creative space
Following along with the theme of software engineers as creators, try to provide ample opportunity for us to be creative. There’s a reason why hack days and hack weeks are so popular – it’s because this is the creative outlet that engineers need to refuel and rediscover their love of code. Hack events are a time when engineers can be completely creative, free from the constraints of their normal jobs.
A hack day every quarter is plenty to get people excited. Want to get people more excited? Give the hack day a theme. Give awards for most creative, most likely to be shipped, and so on. The whole point is to the feed the creativity of the software engineers so that when they get back to their regular jobs, they feel refreshed and ready to contribute once again.
Keep in mind that engineers aren’t special in this regard. Everyone needs time to be creative. In my experience, however, product managers and designers tend to get that far more frequently. There are offsites for management and design summits for designers, yet engineers tend to get left out.
By the way, hack events aren’t the only way to do this, but they are the best way to get started. You can also light the fire of creativity by sending engineers to conferences so that they can keep their skills up to date. Allow engineers to buy books that contribute to their knowledge on the company’s dime. Permit engineers to express their ideas about the projects they’re working on. Google famously gives engineers 20% of their time to pursue side projects. All of this can go a long way towards creating a great relationship with your engineers.
Encourage time off
With the amount of hours and mental exercises we do on a regular basis, engineers need to take breaks. Unfortunately, that’s also something we’re not very good at scheduling. We get so caught up in the process that we forget to take vacations. For the first five years of my career, I think I took a total of 7 days of vacation. I don’t know why, but we’re not very good at making time for ourselves to de-stress. And that’s a problem.
Engineer burnout is unique because we are used to powering through it. When burnout gets bad enough, we leave, looking for relief. What’s more, engineers will probably never tell you that they’re approaching that point; we’re too proud for that. On my last team, I told the engineers that the first time they felt frustrated, to come and talk to me. I didn’t want them to wait until it got so big that the only way they could escape was by leaving. I didn’t want them to leave, I wanted them to be happy, and the only way I could help is if I knew they were starting to not be happy.
Encourage engineers to take time off. Your company gives some amount of vacation, so make sure that engineers are encouraged to use those vacation days throughout the year. One every 4-5 months at a minimum. Managers are in a good place to help with this because they know project schedules.
When engineers take breaks at regular intervals, it restores their creative side by taking them out of the rigor of deadlines. Yes, we will likely still do some sort of coding on our time off, but it will be purely our creation, and therefore quite different than what we do at work. That’s the important part of getting refreshed and ready for the next battle.
Let ‘em code
As ironic as it may sound, a lot of companies hire software engineers and then don’t let them actually code. Instead, their days are filled with useless meetings that inhibit productivity. In general, software engineers are most productive when they can code for at least four hours straight without interruption.
It’s difficult to get into a good flow while coding if you know you have a meeting coming up in an hour or two hours, that’s always in the back of your mind while coding. It is amazingly unproductive to code for an hour, stop for an hour, code for an hour, stop for an hour, etc. You can’t get into a flow and just as you start, you have to stop. The software engineer brain has to switch into a good mode for coding in that switch takes time.
Make sure that your engineers have, every single day, at least four hours of uninterrupted time to code. That’s the key to getting work done faster. It seems fairly logical: if people usually work an eight hour day, at least half of the time should be spent on the main task. I used to find that I was most productive between 1 PM and 5 PM. I knew that if I had that time every day I could easily complete my tasks. When that time started to be interrupted by meetings, I knew I wouldn’t get as much done.
Also, take at least one day a week to have no meetings. That includes daily standups. Just let the engineers have that single day to completely manage their time on their own and get everything done. It is absolutely amazing how much can get accomplished when an entire day is free of interruptions. If necessary, allows engineers to work from home to make sure that they’re not interrupted. I actually went through a period in my career where my manager required me to work from home at least two days a week because I was getting interrupted so much in the office. The results: I got my work done very quickly.
Express appreciation
This is something that can be done immediately and is completely effective. I mentioned earlier the frustration of toiling away to finish a task, only to be met with bugs filed against it. We engineers rarely get a chance to sit back and admire our work, let alone get a pat on the back from someone else.
When an engineer completes a task, especially a long one, a quick note to say thanks will go a long way. Even if it’s just, “Hey, thanks for finishing that up. We’ll take a look.” is enough to diffuse the defensiveness that typically occurs as the bugs start flooding in. Feeling appreciated is important to software engineers because most of the feedback we get is negative, in the form of bugs, production issues, and the like. A little bit of positive feedback makes the rest all that much more tolerable.
For bonus points, set up an award that is given each quarter to the engineer that has made the biggest impact, or improved the most, or whatever. The award doesn’t even have to be something big and desirable like an iPad (though we’d graciously accept it along with other goodies), it could be a little trophy and an email to the team or division recognizing the effort.
And please be sure when you’re thanking people for their hard work on a product not to forget the engineers. I’ve been in numerous meetings and on numerous projects where people openly praised product teams or designers for their work on a project while never mentioning the engineers whose blood, sweat, and tears made the thing real. Every product is a success or failure because of all three groups, no one group could do it alone. Make sure your company always recognizes the team as a whole and not just one particular part.
Conclusion
We software engineers are an interesting bunch. There’s a definite personality that comes along with us, and we really do want to make the best thing possible. If you stop treating us like short-order cooks and start treating us like part of the creative process, you are likely to get much farther, faster than you would otherwise. The teams on which I’ve worked have all had varying degrees of friction caused by not understanding the engineers’ mindset and what drives them. It’s my sincere hope that this article will lead to better communication between engineers and those that they work with. It’s really not that hard. We’re all just people who want to feel like a part of the solution rather than a worker bee.
References
- How designers and engineers can play nice (and still run with scissors) by Jenna Bilotta
- Working with files in JavaScript, Part 1: The Basics
Translations
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
You can leave a response, or trackback from your own site.
199 Comments
“Every single software engineer fell in love with coding because she made a small, useful program early on and was hooked.”
I made a small and totally useless program early on and was hooked anyway…
Thorsten on June 12th, 2012 at 7:47 am
Wow! Have we met? Because I think that perfectly summed up every frustration I’ve had in my working life since…. well, since a long time ago.
Thanks for reminding me I’m not alone!
Richy on June 12th, 2012 at 7:50 am
I just wanted to express appreciation and say “thank you!” for a great article. It’s all so true.
Jörg on June 12th, 2012 at 8:33 am
Hi Nicholas,
Throughout the article, I felt like you were talking about me, I related to all your points, from the point of view of a software engineer. This should be ready and understood by all software team managers.
Thanks for articulating my feelings so precisely!
Yossi Kolesnicov on June 12th, 2012 at 9:33 am
Awesome post Nicholas! This is an absolute must-read for anyone working with engineers!
The part of this article that resonated with me most was seeing software engineers as creators and including them more in the initial creation phase of the software they are crafting. I started my career as a software engineer but now my job is more focused on front-end engineering / user experience engineering. I’ve seen and personally felt this from both ends of the spectrum. Sadly, our industry typically considers the building phase of software a hand-off process to engineering instead of a cross-disciplined collaboration trying to solve a common problem. I think involving engineers earlier not only makes engineers happier but also pleases designers as well. A common complaint I hear from designers is that their designs rarely get build as-designed, usually a result of a hand-off (and usually because of limitations or assumptions not know by the designer or team before it gets to engineering). Getting the right people involved at the right time can really have a huge impact on any project’s timeline, outcome, and morale. I think it can be the difference that moves a project from good to great!
David Mathew on June 12th, 2012 at 9:51 am
Spot on! I’m a coder-turned-PM and this has reminded me of some of the annoyances I dealt with as a coder that I now inadvertently subject my poor Devs to. In particular, firing off bug reports before I’ve shown appreciation for completing the work, and asking to push on with progress before requirements have been finalised.
The interruptions issue is tricky: I’m 100% aware of and embrace The Zone .. yet PMs can’t do their job (ensure project is on track) without feedback from the Devs. Thought provoking stuff, thank you Nick!
Ben J on June 12th, 2012 at 9:59 am
The first assertion that Software Engineers are creators is only partially true. You are failing to realize that the entire team of product managers, designers and testers are also part of the creative energy here.
Shaun on June 12th, 2012 at 12:12 pm
Actually, my statement is 100% true. Software engineers are creators. The fact that others are creators doesn’t negate that. And I suggest you read the article more closely, because I did say that both product managers and designers were creative. For example:
Nicholas C. Zakas on June 12th, 2012 at 12:14 pm
Interruptions are definitely a part of software development, but it doesn’t have to be constant. Providing some interruption free time is key to getting good productivity from software engineers.
Nicholas C. Zakas on June 12th, 2012 at 12:15 pm
Love this article. You are so right in many ways.
lisa on June 12th, 2012 at 12:33 pm
As usual, a brilliant post my friend. Well done. I forwarded the link to a number of my co-workers and more importantly, management and product teams.
Mike Shaffer on June 12th, 2012 at 12:39 pm
WOW!
You’ve definitely hit the nail on the head. It’s as if you live in my head. You could not be more accurate in what you say. If only everyone else realized this. Amazing insight.
Jason Barrera on June 12th, 2012 at 12:43 pm
I really like your blog in general, but I think this particular entry is one of your best. This post is amazing and so very true. Thank you so much for this great write up!
Alexander Trefz on June 12th, 2012 at 2:02 pm
Absolutely true. Specially about the flaw of overestimation of knowledge, abilities and ego. Thank you.
Ali Rokni on June 12th, 2012 at 3:08 pm
Really great article, thanks for writing it .
Craig on June 12th, 2012 at 3:16 pm
This post hits the target with Robin Hood-like accuracy. I’m tempted to send it to my boss.
Buzz on June 12th, 2012 at 5:09 pm
[...] read a great article about the psychology of software developers this morning. It rang true with my experiences of [...]
Software Engineers are Creators, Not Builders « Johno's Place on June 12th, 2012 at 6:06 pm
Awesome article. Thanks
Thomas on June 12th, 2012 at 6:38 pm
An amazingly written and accurate piece. Exactly what I go through…. Great, great, great, great article.
EA on June 12th, 2012 at 7:49 pm
Nice work, as always. Here’s my secret to highly accurate time estimation:
“When will it ship?”
“It will ship one week after a) the last design change or b) the last time somebody asks me when it will ship.”
Kent Brewster on June 12th, 2012 at 9:19 pm
Amazing read! Thanks for taking the time and sharing!
Phillip on June 12th, 2012 at 10:25 pm
Spot on!
Glenn Lawrence on June 12th, 2012 at 11:13 pm
In my company, engineers are coding machine. We don’t have the right to have our own input.
Coding Monkey on June 12th, 2012 at 11:28 pm
Did you purposefully misspell “pendantic”? Nice.
James on June 13th, 2012 at 12:26 am
You are a mindreader! God bless you for putting out exactly how I feel. People mistake my grumpiness and think I hate being a software engineer. Oh! but I love it! If only you allowed me to be one.
G3 on June 13th, 2012 at 12:55 am
great article that sums it up nicely!!! am leaving a company in favor of their competition because of exactly these and other ‘communication’ issues. at one point i found myself defending the use of object-oriented coding methodologies in general if you can even believe that – i still cant get over that one. its also helps to keep track of previous conversations on behalf of the stakeholders, especially ones that directly led to the drawing of conclusions and then to provide a summary at the beginning of the next meeting so everyone is on the same page – we ended up going around in circles like it was the twilight zone or something because i assumed we were all tracking the design process.
zaph on June 13th, 2012 at 1:43 am
Just to add to the comments above, this article is a superb articulation of my experience as a dev.
Dave Saunders on June 13th, 2012 at 1:59 am
“Software engineers are creators” Not true. “Some” are creators. But some are builders, some are wasters and there are many other different types. Especially if you have a multinational team.
Ian on June 13th, 2012 at 2:19 am
Most of what you have written is applicable to what I find, however I do disagree with a couple of points:
1) Shipping / end of a project: You correctly say that we treat our code as though it were our baby. One of the joys is seeing our babies grow up. I don’t cut the apron strings (to continue the baby anaology) when the product is first productionised. There are always new ideas / new enhancements etc that can be incorporated and I never ‘finish’ a project – there is always more that can be done. One of the joys is taking a small, simple idea from a small, simple project into a mature product.
2) Money: Money is important. Yes, we code for pleasure but we want meaningful remuneration for our work. We need to eat, pay rent / mortgages etc. Paying the PMs 3 or 4 times what you pay us is unfair. We are all in the same team. The fact that we enjoy what we do is important; but it can be thwarted by seeing iniquities in the rewards being handed out.
jsc42 on June 13th, 2012 at 2:27 am
Great article, which expressed underlying causes so well of the frustration I have been feeling at the moment with a huge project going live. Burnout is one, rhetoric from a manager well-versed in code is another – despite that what might work for one person doesn’t necessarily work for another.
Two points in particular:
1. While I thrive on creativity and solving problems that provide real value for others, money should not be overlooked. My concern is that the powers-that-be would take that as an excuse to pay an unfairly low amount considering our skills (one could argue as being in a similar league to doctors) and experience. To learn that my finishing salary at my previous job was equivalent to the starting salary of a junior bank teller at that same time was insulting.
2. In reality I find it rare to be able to enter the zone for such a long stretch as 4 hours, even if I am uninterrupted. While the work environment often plays a part, in most cases the particular task either doesn’t take anywhere near that long or encounters a roadblock where I need to co-ordinate or discuss with another person. I’m also aware of the need to take regular breaks, both mental and physical.
The times when I am passionately engaged and in ‘the zone’ are when I have a clear understanding of what is required and why, and have the autonomy to be able to achieve it without fear of my implementation being micro-managed. The other common theme is that I’m genuinely excited by what I’m creating or enhancing and the value it represents.
Daniel on June 13th, 2012 at 2:37 am
Wow. Like others said, this article perfectly describes my mindset, the way I work, the way I feel about work.
This article is the rosetta stone of the engineer. We should print it, and distribute it around when we meet new coworkers. Seriously.
Piwaï on June 13th, 2012 at 2:50 am
I can’t over state, just how much this article is right. It could be titled, the care and feeding of Matt Fellows
Matt Fellows on June 13th, 2012 at 4:11 am
Absolutely hit the nail on the head here.
Andrew Johns on June 13th, 2012 at 4:56 am
..sniff…. I think I just shed a tear. ..sniff.. that was beautiful…
Nicely done Nicholas C. Zakas,
I will be more than happy to pass this on.
..abow..
aBitOWhit on June 13th, 2012 at 5:02 am
Excellent article. As I wrap up my 29th year in this profession, I still need to be reminded how and why I get so burned out. (I am currently persuing other opportunities to escape the current burnout)
Interruptions – At one company where I was the technical manager of a group, we set it up so half the group had “office hours” in the morning, the other half in the afternoon. Productivity went way up. Futhermore, it is amazing how people can solve their own problems when help will not be available for 4 hours.
Last comment, you express yourself to well in words to have been a good software developer.
RY on June 13th, 2012 at 5:03 am
I have sent this article to my Business Analyst. If she reads it the shock may prove more than my dried up old heart can withstand. Like the author I have been told to start coding a project with no clue as to what the PM, client or my management wanted.
Earl Owens on June 13th, 2012 at 5:30 am
brilliantly written
bhavdeep on June 13th, 2012 at 5:39 am
Get out of my head!!!!!! Honestly, this article spoke to me in so many ways. Passing this onto my entire department…especially the managers.
Eric Davis on June 13th, 2012 at 6:09 am
Extremely well stated! That point about getting a chance to admire one’s work is so true and poignant. Thanks are far and few between…and although they are understandably absent they are nonetheless craved.
J. Scotte Barkan on June 13th, 2012 at 6:26 am
Best.
Article.
Ever.
thank you so much.
Brandon on June 13th, 2012 at 6:27 am
you are talking about me . .
Luponk on June 13th, 2012 at 6:58 am
As a Program/Project Manager that has several software engineers that work for me, I found this article to be very insightful. With any luck I can apply what I’ve forgotten … yes – I used to code – LOL. I’ll never say THAT again!!
Bill L. on June 13th, 2012 at 6:59 am
I’ve skimmed a bit of this, so I may have missed a detail or two…
Generally dead-on. I’ve used the “build code like a house” metaphor before and managers instantly reject it because you have to have a solid definition of what you want before you start (try building a house using Agile or XP methods – do you know how much builders charge for change orders?).
I’ve found that a manager’s job is to minimize obstacles, and in almost every case, my requests for more information become obstacles, so I get to be “minimized into oblivion”. It’s not enough for them to tell me they are experts at doing my job because they wrote an Excel macro once, now they have to trivialize what I do because actually building the product is an obstacle to their success!
So, after 35 years in this business, I’ve learned I’ll never be allowed at the “adult” table simply because my questions about what people really want make them aware that choices have consequences for which they may be held accountable and this terrifies almost every manager designed I have ever known. So, to make problems go away, make the software engineer go away.
Jeff Griffith on June 13th, 2012 at 7:02 am
Perfectly articulates almost every frustration I experience as a developer on a daily basis. Sending to upper management………now.
Kevin on June 13th, 2012 at 7:11 am
Nicholas, thanks for this really great post. I have more than ten years as a software engineer… from my personal experience I have come to realize a lot of the same things you wrote, and I wish that someone had told me this things before I started on my first job.
Greetings from Argentina.
Federico Gamondés on June 13th, 2012 at 7:28 am
Excellent article, it really hit the spot on pretty much on every aspect. It’s kind of sad that so many people are in this situation (me included), since a lot of programmers, like you say, plain just quit their jobs because of all this, and sometimes even lose their love for coding.
I actually am part of this last group, it wasn’t until i started working on a personal project that i re-discovered i didn’t actually hate programming, what i actually hated was all you say in this article, and i felt totally refreshed, loving to code again.
Thanks a million for this article, it helped me so much. Keep it up!
Joe M. on June 13th, 2012 at 7:35 am
I think that everything has been said, but still I needed to tell you that I thought you read my mind and expressed all I have felt and went thru the past 10 years.
Thanks a lot for this wonderful article that visited both sides of the coin.
French speaking here, so be nice about the syntax…
Yanick on June 13th, 2012 at 7:53 am
Dr. Daniel Kahneman has shown that capability biases are universal–don’t just highlight software engineers!
Your article has a serious rhetorical conflict. Early on, you emphasize that engineers are not just builders waiting for instructions. The later, you Campari them to soldiers you just want clear instructions. Do we want decision-making power or not? And what kind of decisions do we want? A big problem for engineers is communication.
The first thing an engineer should do when she gets incomplete requirements is to write up a multiple choice questionnaire with all the prerequisite decisions that have to be made. She should also make up a long list of possible things the product manager and designer might want and forgot to mention, including extra time estimates (times 4!) for each, and send all that back. Third, she should look into any other products that do things like or similar to what is being asked for, to also forward to concept people.Then, she should start researching any new algorithms and architectures that have a high probability of being needed. When the responses to the QA, missing features and comparison products come back–in writing only, please!–then she’ll be ready to get to work with all assumptions made explicit, and the time cost responsibility squarely in the product manager’s lap.
Brent Gulanowski on June 13th, 2012 at 7:59 am
Compari->compare. Autocorrect!
Brent Gulanowski on June 13th, 2012 at 8:00 am
You are extremely right in every single way.
As both front-end and back-end developer at the same time, everything you said fits perfectly in my profile for both tasks.
You almost got me depressed for showing that it could be so much better, but in my company no one would ever listen to any of this. In my company the product managers are seriously the worst of the worst and much worse than you described. They only care about sales and reaching their targets while leaving a trail of destruction behind them and every month someone has a burn-out.
I find it very hard to find a company to work at (in The Netherlands) that actually appreciates engineers and uses a healthy project management team that works efficiently.
And in my case, a higher pay would definitely make me happier since reaching the end of the month is a challenge every time and I feel seriously underpaid, but it’s indeed not the most important factor. Still, they screw me over every time anyway, I might as well get some money out of it.
Ruben on June 13th, 2012 at 8:00 am
I have no idea what it is like to be a software engineer. But I do know what it is like to try and work with them. This article is a dead on representation of the behavior and attitude I have encountered in working with them….but I don’t think that makes it “great” I think it makes the problem worse.
#1 – Grow up and stop complaining. The frustrations described here are universal to creative and non-creative employees of all industries, not exclusive to software engineers. I have worked in a variety of industries in my career, I have worked with traditional engineers as well as software engineers. The only difference I can see is the engineers act like prima donnas and seem to have a very narrow perspective on what they can/can’t do. (In fact they exhibit very limited creativity on problem solving that does not involve code). This of course only serves to alienate them further from their co-workers creating a downward spiral of negativity that is corrosive to companies.
#2 – The rush, rush, rush of the software world is a huge problem for the business world today…again, not just engineers. And, I would argue, is a world created by in large part by software engineers who like to constantly re-create, improve and roll-out their latest brain child. When you start the ball rolling, you also have to deal with the consequences. Technology has created a world that does not emphasis thinking things thru, planning or due diligence. It is rude to create a world like that and then bitch about the consequences to yourselves.
#3 – In my experience if software engineers spent as much time thinking things thru as they do complaining about how everybody else is messing with their ability to get their jobs done life would be a lot smoother for them. Nobody wants to hear about your problems getting your job done, they are too busy trying to deal with obstacles to getting their own job done…and not whining about it to anyone who will listen. You can be the greatest coder in the universe, but if there is no one to sell it, implement it or support it is just useless code. Try to get along with others instead of pitting yourselves against them.
#4 – If you don’t like the constraints with your career, find a new one or find a way to fix it yourself.
Miss Kitty on June 13th, 2012 at 8:00 am
I read this article with a smile on my face…was as if I wrote this myself!!
Great article and I’ll be sharing with others for sure
Neil on June 13th, 2012 at 8:10 am
Well said Nicholas!
Judging by all of the positive comments Nicholas has received, it should be apparent to most that these problems are not specific to their own company but to the industry as a whole. This is not to say that every company runs a sweat shop; there are certainly a lot of great companies to work for that understand how to manage software engineers.
However, for those who are unfortunate enough to find themselves ‘flipping burgers’ I would highly recommend ‘Uncle’ Bob’s latest book ‘The Clean Coder’. Robert Martin does an excellent job of explaining how we as software engineers have gotten ourselves into this situation and how we as software engineers can get ourselves out.
Chad Leeper on June 13th, 2012 at 8:27 am
Great article… I can related to 99.9% of it – unfortunately the scenarios you describe are all too common.
Diane on June 13th, 2012 at 8:43 am
La Forge:”Yeah, well, I told the Captain I’d have this analysis done in an hour. ”
scotty:”How long will it really take? ”
La Forge:”An hour! ”
scotty:”Oh, you didn’t tell him how long it would *really* take, did ya?”
La Forge: “Well, of course I did.”
scotty: “Oh, laddie. You’ve got a lot to learn if you want people to think of you as a miracle worker. ”
a lot of times i dont give an estimate. when im asked i answer honestly “i have no idea” a lot of times i havent even examined the problem space, it could take me a day just to give an estimate on how long it would take (in some cases i might fix it while im figuring out how long it will take, since part of that is finding out why its broken)
some problems look like they are straightforward and easy to fix/implement then turn out to be a lot more complicated than they seemed. some seem like a huge tangled mess but then you find the solution just falls into place. estimates are a pain.
but this article is dead on, especially that house analogy. as an example:
one time i was working on some software and 2 days before its going to be showed off at a big conference the boss says he wants to make a “small” change, this change completely changes how that section of the program works, undermines key assumptions in the software and is in general a bad idea. i raised objections, every engineer working on the project raised objections. i did manage to macguyver something in place by the deadline but it was a horrible mess of code.
austin on June 13th, 2012 at 8:43 am
10,000% agree! While reading, I actually felt like your narrating the story of my professional life. Thanks Sir Nicholas Zakas!
Joel on June 13th, 2012 at 8:48 am
With tears and cheers, I will save this article to my own small and special collection.
Really thankful to what you wrote.
David Wu on June 13th, 2012 at 9:10 am
Great article. Agreed with a lot. Only disagreed with one statement:
True priorities aren’t transient.
Well, when there is uncertainty in the “true priority” (due to uncertainty about some aspect of the marketplace that your product is trying to address), then as more information becomes known, the priority changes to reflect that information. I believe this to be the primary reason behind “product managers who always change their mind”, and the sense that “the requirements are always changing”.
Would it be nice to have static plans and completely waterfall the process of implementation? Sure, but if you did, chances are there is nothing unique in your product, and thus no reason for anyone to need it since an “established” solution already exists.
Designers and Product managers might know more than we engineers do about how common it is that successful products had to stumble around for many iterations before discovering the target market and the reason why someone would buy the product.
I think the biggest tragedy is that a Product manager or Designer fails to tell the engineers that they don’t know everything about the product, and as a result the team is going to have to do some prototyping phases with user feedback to try to learn what is not known (also called Product Research). This may mean you work on stuff that doesn’t make it into the final product, but the work is still incredibly valuable, because the team can’t figure out what is needed without building a first draft and testing it.
The phrase “fail early, fail often” comes to mind to describe what turns out to be an efficient process for product discovery.
Kent on June 13th, 2012 at 9:16 am
You can easily swap the word “software” to “hardware” and the article is still valid for engineers / developers.
In fact anyone directly and deeply involved in the creative process (i.e. hands on) within any engineering discipline this article holds true.
J Desimone on June 13th, 2012 at 9:32 am
Awesome Explanation. Great, Thanks
Karunakar on June 13th, 2012 at 10:00 am
@Ian – I have to disagree. Once again, those engineers are being forced to act like builders.
Nicholas C. Zakas on June 13th, 2012 at 10:26 am
@jsc42 – I think you may have taken my statements a bit too literally. I agree that most software projects are never actually finished and continue to grow. But you do take time at each major milestone to stop and admire your work. That is “done” for the moment.
As far as money goes, there definitely should be pay equity among all of the members of the team. If PMs are being paid much more than engineers, that’s a problem. My point was more that you don’t actually get more out of the engineers by paying them more. Pay raises are satisfying for a day or two, but they don’t keep you satisfied long-term.
Nicholas C. Zakas on June 13th, 2012 at 10:30 am
@RY – I absolutely love that approach!
Nicholas C. Zakas on June 13th, 2012 at 10:31 am
Excellent article on the way techical and non tecnical people see their jobs. The part about inturruptions and “the flow” is particullarly relevant as many non tecnical people see computer programming as nothing more than typing and don’t see the harm of interruptions.
Once more with correct website, delete the first.
Tim Rotella on June 13th, 2012 at 10:50 am
Thanks for this article. It reminded me why I enjoy being a software engineer, and brings to the spotlight why I enjoy some projects and not others. Love the house analogy. I also get frustrated with the “few lines of code” comment. My response, “It about complexity. Is a one mile walk up Mount Everest the same as a one mile walk up the street?”
Julie Bee on June 13th, 2012 at 10:55 am
@austin – unfortunately, deadlines will always be part of the process. Getting better at estimating will only serve you well in your career.
Nicholas C. Zakas on June 13th, 2012 at 10:57 am
@Brent – I’m not sure I understand your initial statement. I am a software engineer that’s why I write about software engineers. If I were a doctor I would probably write about doctors.
In regards to your rhetorical conflict comment, I believe you’re reading something into what I wrote that isn’t there. Software engineers are creators, that much is true. We don’t want to be builders, but we tend to end up that way. When we have to act as builders, then it helps to have more details because unlike with our own creations, we can’t read other people’s minds. And because we’re so used to creating, we can usually tell that there are gaps in the description that prevent it from becoming a real thing.
I’m not sure if your suggestion about writing up a questionnaire is intended to be serious or not, but I think that’s not the right way to go. Including the engineer in the initial discussions is the best way to identify gaps early. Throwing acquirements over the wall and then from the questionnaire back isn’t cooperative, will take longer, and doesn’t help the situation much.
Nicholas C. Zakas on June 13th, 2012 at 11:00 am
@Miss Kitty – I’m glad you found the description in the article to be accurate, though I’m disappointed that it didn’t lead to a better understanding of why that behavior exists. My hope was that this article would help people like yourself to better understand the mindset of engineers and therefore be able to work with them better. It sounds like you have had frustrating experiences the software engineers in the past, as many people have. I can only hope that you will reread this article and use the information here as a way to create more cooperative relationships with software engineers in the future.
Nicholas C. Zakas on June 13th, 2012 at 11:04 am
Hats off.. every word true..
Satish Maurya on June 13th, 2012 at 11:06 am
@Kent – true priorities can’t change, that’s a makes them true. The problem is that most people and companies are bad at identifying true priorities. A true priority is general such as customer service, communications, etc. I like to take GitHub as an example. It was clear that their number one priority when starting out was to provide a platform for social coding. They build out the site according to that priority and didn’t waver from it. All the other features, using git, pull requests, activities, these all fed into that true priority. They knew what the product was supposed to do and kept everything in line with that.
Certainly products go through iterations, but each product has a true priority. EBay is for auctions, Amazon is for selling, Google is for searching, and so on. Taking some time to figure out the true priority means that all of the tasks make sense insofar as they feed into it.
Nicholas C. Zakas on June 13th, 2012 at 11:09 am
Nicholas
Many truths stated here.
I am in a small group of 3 developers and we have been working on a never ending project (4 years) suffering from scope explosion! We are simply burnt out and ready to leave. Currently begging the project manager to please SHIP IT!!!!! But perhaps we have not pushed back enough because when the PM proposes another new feature or change our pride wants to stand up and say “Sure we can do that” Like somehow it’s a reflection on our ability if we say no.
We loved the article.
Burnt on June 13th, 2012 at 11:16 am
I’ve never worked at a company where I wasn’t supposed to give input into how the product was supposed to work. You’ve clearly worked at all the wrong companies.
Ted Schroeder on June 13th, 2012 at 11:25 am
@Ted – consider yourself lucky.
Nicholas C. Zakas on June 13th, 2012 at 11:27 am
Wow, great article.
As a few have said I felt like you had been sitting next to me watching as I’ve worked as software engineer for the last 25 years. The section that actually made me laugh was “I used to code”, I get that all the time and had a manager actually make the statement “What’s the big deal, it’s only a few lines of code.”. It’s become an internal joke at my work place. At the time a co-worker was present and came back with the classic retort of “The 2 lines of code isn’t the hard part, it’s figuring out where they go thats hard”.
It appears that soon I’ll be promoted to a more senior management position so this was a very timely article for me, I plan to save a copy of it and use it as a reminder of what I suffered over the years at the hands of managers that either totally misunderstood software development or simply didn’t care.
Ken on June 13th, 2012 at 11:43 am
Thanks for taking the time to express your thoughts and do justice for the software engineers.
It is a long article, I appreciate the effort and I hope you don’t take this the wrong way.
At one point you use the word “re-acclamation”. If it is a typo “mea culpa” though “a” is far from “i” on the keyboard. It is “re-acclimation” what you wanted to type and say.
Cheers,
Mircea Ion on June 13th, 2012 at 12:14 pm
You’ve written an excellent blog with many issues that could be their own blog topic. There are at least three issues you raise that contribute to software engineers’ grumpiness that we are getting closer to solving by employing Agile methods: coding before there are enough requirements, inaccurate task estimates, and requirements changes.
Agile methods are no panacea and are only as good as the Agile coach and the willingness of the team members to change their thinking about the creative process. Consider the design process for example. Acceptance test driven development allows the engineer to collaborate with the customer and the designer to begin building something deliverable very quickly and to refine it as development continues. On my Scrum projects, team members are asked to regularly adjust their estimates by indicating how much time is left for them to complete a task. People are often, initially, reluctant to come up with a task estimate. But once they realize that adjustments to time or scope are expected because of time needed to learn how to attack a problem or other issues, the self-inflicted time pressure is mostly resolved. Lastly, we never say “no” to a customer; the worst case is we say “not now”. While there are times when a small change is requested and a development engineer agrees to make the change, the standard approach is to build the new function as was agreed during the day to day collaborative work. If the requirement change is too onerous, we agree to put the change on the Product Backlog. It’s then up to the customer to decide if they really have to have the change made right away, in the next sprint iteration, or put it off to a later sprint.
I look forward to reading more of you insights.
Bob M. on June 13th, 2012 at 12:25 pm
@Ian
“Software engineers are creators” Not true. “Some” are creators. But some are builders, some are wasters and there are many other different types. Especially if you have a multinational team.
What is your point? What you just said stands true for any other profession. You’ll always have some bad seeds.
Mircea Ion on June 13th, 2012 at 12:29 pm
@Mircea – I’m glad you enjoyed the article, and thanks for pointing out the typo. I actually dictated the entire article so I’m not surprised there are more than a few typos.
Nicholas C. Zakas on June 13th, 2012 at 12:47 pm
Insanely great article. You just ripped apart a typical software engineer’s psychology. There might be more nuances and variations but the basic outlay is perfect. Appreciation for “finishing it up” is sooooo true!
goodsammy on June 13th, 2012 at 12:57 pm
Lots of great points, and a good read. I used to code so I know.
The house building / garage analogy was great, but if I was paying someone to build a house, I’d want them to come back to me and say, “I’m building the 1 car garage, detached.” allowing me to confirm or elaborate on the requirements.
I think the one thing you missed (and really ignored entirely) is the Agile movements goal to have the developer and business stake holder collaborate together and discovering and understanding the requirements that matter, as they are needed to be understood (avoiding the blue paint requirement early for instance.). And, that ends up allowing more creativity for the developer (“oh great, another 2 car garage”, could be replaced with “I was thinking a garage with a backdoor so you could drive extra vehicles into your backyard to park on your basketball court when street parking is full and you have guests over”)
If you are still reading and care about the craft of software development, you can see what I work on here, http://www.zspace.com. We have some software dev positions open as well.
John C. Ware on June 13th, 2012 at 1:54 pm
@John – I’m not sure I understand how I didn’t address the business stakeholder and engineer collaborating. I’m pretty sure that was one of my major points in the “care and feeding” section (see “Work cross-functionally”). I can’t blame you if you stopped reading before that, it is kind of long. That being said, I don’t mention Agile because I don’t think that it has a monopoly on good development practices.
Nicholas C. Zakas on June 13th, 2012 at 1:57 pm
Hi Nicholas
Wow, record length post! Thanks for this thorough and well written article. I’m a software engineer and you’ve hit the bullseye over and over again with this entry. I read The Mythical Man Month by Fred Brooks a while ago (must read for every PM) and there are many similarities between this book and your post. The book was first released 1975 and it’s incredible that we’re still dealing with the same issues in 2012.
TJ on June 13th, 2012 at 2:45 pm
Wonderful article. I’m a SW engineer for a more technologically fossilized portion of our profession (avionics. FAA gets cranky when the plane crashes), and it is still an excellent summary.
Leslie Schweitzer on June 13th, 2012 at 3:30 pm
I suggest you look up the meaning of “engineer”. Yes, engineers ARE builders, and there is nothing WRONG with that. I also advise you look up “architect” and “designer”. Unless you have a very wide definition of “create”, at which point, building is creating
Builders and integrators are NOT “short order cooks” as you attest. If anything, you are showing the mentality of why many look down upon so called “software engineers” as nothing more than primadonna’s with a chip on their shoulder.
All you are saying really, is that many companies don’t believe in engineering practices, and treat engineers badly.
The reality many developers are labeled engineers, yet don’t follow engineering practices, and really would be best served being labeled architects and/or designers. This is not really their fault, as this has unfortunately been the trend in most companies. This likely hurtst more than it helps.
But going to your original point of “no” vs “yes”. People need to learn to say “yes, but”. Everything is doable, but has a ‘price’ associated with it. People just need to be engineers
Disclaimer: Electrical engineer that has worked as a developer at times in his career
Javier on June 13th, 2012 at 4:05 pm
Very good article Nicholas! Very helpful for Engineers and Managers alike.
Sameera Rao on June 13th, 2012 at 5:35 pm
Great article, all True; and now I know how spoiled I am. I must be one of the luckiest Software Developers. My first full production job, I was given problems and who was involved. I got to figure out what the real problem was and provide the correct solution … Gave an estimate, which was taken as fact, and delivered; learned real quick figure an estimate then “triple” it – on average, not bad. Manager got involved only to help “prioritize” list of problems. Next position, I learned real quick how spoiled I was before; would have still been with prior company, but it went away. Still advantage in that I was the only Software Developer on the product and was given a list of changes that I got to figure in. Also got to figure Estimate, again triple original usually worked. The pesky Marketing people who insisted “we will just all agree that the estimate is X”, considerably shorter than mine. Their Estimate I got to ignore. Even with the shouting matches “You Agreed with the Estimate!”; my response, “NO That Is Your Estimate! Mine is not past, yet!”. Again company (that bought us) went away. Current position, rarely timelines … yea!!! Interruptions, major problem, but part of the job. And, no I am not the boss.
Diane Porter on June 13th, 2012 at 5:47 pm
It’s like you know me! Great article.
Matt on June 13th, 2012 at 7:02 pm
Great article, all I can say to it is: I’m not alone!
How many times have I had to “assume”, to eventually be told it’s not ok.
Happened even for a project I’m working on right now, where after a first presentation weeks ago, everything was fine and we could keep moving on to second phase, only to learn that some functionality must now be changed, that will also affect the database behind it, and the presentation layer…. oh the joys of not having enough information, with one of the most important being: milestone must be completed by [date].
But no matter what, I’m sure many will agree on this, I wouldn’t do anything else with my life!
Richard on June 13th, 2012 at 9:03 pm
I have been a Software Engineer for 15 years. This is the most accurate description of my day to day life I have ever read. This should be mandatory reading for Senior IT management. Great article!
Roy on June 13th, 2012 at 9:25 pm
Consider how software engineers are educated and trained. we are given an assignment. We have no knowledge of the final product or what it is supposed to do. We are not asked what approaches can or should be used to generate a final product. We don’t even have any input on the time schedule for producing the product.
Supposedly, this mimics real world software engineering where you may get a set of pre-conditions and post-conditions. Maybe, you will be given a set of parameters that are to be passed from the calling function.
This is typical of some programming paradigms.
Often, however, the product is based on a real world activity even in an educational setting. The glitch is that the software engineer doesn’t know or understand how the activity is performed before being transcribed into a software program. The result is that software engineer design something that the user can’t even relate to in the performance of their job function.
IMHO, that is a major missing component of the software design puzzle.
Even at the educational level, students are not involved in the discussion and design of a project.
Current educational paradigms seem to focus on the code process and forget that design follows function, and the paradigm and methods of a job description are the function that software is supposed to make more efficient.
The attitude of many administrators is that the programmer doesn’t have a need-to-know. The coder just has to produce.
Michael R. on June 13th, 2012 at 9:28 pm
I swore up and down I would never code, but I needed a utility program specific to my job. I asked a Computer Science friend to write it for me and he said, “No, you do it.” My protests fell on deaf ears but he did give me enough code for me to finish it on my own.
The next year I needed some updates to the utility and hey, while I am at it, let me add some functionality. That small useful program introduced me to a career I never thought I would love and I haven’t looked back. I still have the program, though its’ usefulness is long gone.
Erik on June 13th, 2012 at 10:02 pm
Briliant. Hits the nail on its head. Thanks!
Anirudh on June 13th, 2012 at 10:29 pm
This is amazing artical . I am able to relate to almost all points.
Vedangi on June 13th, 2012 at 10:31 pm
As I read the part about engineer creators I was reminded of this quote:
Scientists study the world as it is; engineers create the world that has never been. – Theodore von Kármán
von Kármán was one of the engineers that worked at NASA on the Mercury, Gemini and Apollo projects.
What is truly sad is none of this is really new information. These same points have been made for decades and managers STILL either don’t believe it or are willfully ignorant.
I just left yet another company for these very problems and have decided to try my hand at consulting. At least I will have some control over what I do. Wish me luck!
Joe Stockton on June 13th, 2012 at 11:05 pm
You may be interested in the examination of the “widget factory” vs “film crew” organization models discussed here:
http://programmers.stackexchange.com/questions/45776/why-do-business-analysts-and-project-managers-get-higher-salaries-than-programme
The “short order cook” designation maps fairly well on to the “widget factory” model; the film crew is its contrast.
Weston on June 13th, 2012 at 11:37 pm
[...] cased you missed it, Nicholas C. Zakas wrote a great post about the care and feeding of engineers and why they’re so [...]
Engineers and other anomalies | morgamic.com on June 14th, 2012 at 1:43 am
Hi Nicolas
Some excellent points and suggestions and I agree with many aspects of your analysis…
….However, blessed shall be the software engineer who is flexible and able to adapt to rapidly changing business environment and demands …and that requires a special blend of creativity!
The ability to be flexible, recognise that you are not Van Gogh who doesn’t care if the buyer likes his art or not, as long has he can be an artiste and create…knowing that your creativity is required to address a business need, normally paid for by some customer (bespoke rather than creating something you like and then seeing if there’s a demand).
When you are using your own dollars to invest in intellectual property, you always have the freedom to make your own artistic decisions but when you are in a profit driven organisation and there are shareholders involved, best understand their dynamic and your role in the organisation, otherwise they do get twitchy and (sadly) artistic appreciation starts falling by the wayside!
They need your creativity but only in as far as it helps them refine and enhance their vision and ideas that were researched by specialists in their field (e.g. Marketing, Product Designers / Managers etc.)
If your creative input in that context is being stifled, it’s time to move on, but in my view for most SE’s (and you certainly are an exception) it’s a pipedream to expect to be an “independent” artiste in a commercial environment today.
….so if an SE is feeling that their creative muse is not being appreciated, take up art classes after hours or become a Product Manager
I liked many of your suggestions of how to create a healthy environment for SE’s…e.g. drawing SE’s into the meetings and process earlier on …I agree with that as you will then be able to point out all the flaws in the script earlier on and avoid/minimise late projects, rework and all the other nasties that come with software development projects. The truth is from the time an idea is conceptualised to it’s implementation, many variables could present themselves that were not apparent up front (contrary to popular belief Product Designers/Managers are not omniscient either, although they may think so:-)…), a dynamic changing project is inevitable. Where there is a great level of trust and respect for each role within a team changes requested will not be viewed as frivolous but necessary.
You would have enjoyed the earlier days of development (30+ years ago) since it was shrouded in mystery, SE’s were revered as demi-gods AND there was time to be creative….no-one could argue with your opinions or ideas as you were the expert. Y2K (remember that) changed everything…the very creativity used by SE’s ended up creating the Y2K issue that got the world doing one of the largest global projects ever to fix the code….so unfortunately the street cred of SE’s has diminished considerably among Execs, to the point where you now mainly have “builder status”, business will tell you what to do and almost how to do it…blank cheque projects have disappeared in the mist.
So while I can appreciate your sentiments, I feel SE’s need to find ways to still be creative but within the constraints of today’s IT challenges and business environment. If you can find ways to help an organisation adapt quickly to market demands, you will be worth your weight in gold!
Today’s key skills are the ability to adapt quickly and networking skills…Millenials have waxed the latter…
All the best, continue to push the boundaries….would have loved to have someone like you on my team!
Marina (Baby Boomer)
p.s. You should be glad your date didn’t work out, as you would have been assigned to life of misery with someone who doesn’t understand the rigours and requirements of IT (long hours, nights, etc.)…how on earth would she have handled overnight standby with phone calls in the middle of the night?
Marina on June 14th, 2012 at 2:02 am
This lifted my heart. Yes we are a creating bunch. Really, I suffer most when my creative skills are not taken into account. I think it’s a very flawed state of affairs in these days that often in companies, in order to get into creative positions in a project, people have to give up on the engineering position.
Your solution, that engineers to be involved in the creative process can fix this perfectly. Of course, it seems only logical, but far too many times it’s not followed.
Cornel Rebegea on June 14th, 2012 at 3:02 am
Dont normally comment on posts but this article “clicked”. 100% true.
Sometimes the grumpyness is just lack of coffee. A work space without coffee? What kind of job is this!
Dave on June 14th, 2012 at 3:34 am
Thanks for this article, this pretty much sums up the lot of the coder.
Tim on June 14th, 2012 at 3:45 am
This article has captured the crux of the problem.. And for these reasons plus the excessive stress involved in meeting deadlines, I’m moving out of development… Though one thing i disagree is about money… Money is definitely important.. in fact a very good motivator… esp if the rewards are monetary…
Sarah on June 14th, 2012 at 5:25 am
“Money allows them to have fun, but what really interests us is coding and creating.”
“make sure that engineers are encouraged to use those vacation days throughout the year”
As much as I agree with everything you said, I feel like you have downplayed money a bit too much. More money means a better use of the vacation days I take and more fun at night and on the weekend. Both of which contribute to me being more recharged when the next time I go to work.
Is it as important as job satisfaction to me? If I’m already making a comfortable living, and can do everything (within reason) I want to do with my free time then absolutely not. If I’m paid under the market rate and am offered a 100% raise to work in an environment I suspect I wouldn’t enjoy, I might just take that risk…
Nate on June 14th, 2012 at 6:40 am
This is my bible now.
Lino Silva on June 14th, 2012 at 7:09 am
As a software engineer, I recognize that in the workplace I have two major flaws:
1) I don’t say “No.” far enough. I’m too much of a sucker that way.
and
2) I’m far too honest. Now being honest with other developers is important. You need to know the fine details when your code connects to somebody else’s. But in all other regards, being honest usually just ends up biting me in the ass. Those who say honesty is a great quality, they are liars. Too many people are of the belief that “If I ask you a question, tell me what will make me happy.” rather than “If I ask you a question, give me a truthful answer.”
On the topic of what the article covered however, I can only say one thing: “GET OUT OF MY BRAIN!”
… Except for the part about the money. Anybody who wants to throw more money at me to help solve problems is free to do so.
Bret on June 14th, 2012 at 8:03 am
Thanks for posting a well-reasoned, thoughtful, and balanced article. Like many others, I relate to and substantially agree with the article. I also liked the comments, and especially related to Jeff Griffith’s comments.
As George Box wrote, all models are wrong but some models are useful. The house-building analogy is useful, as long as it isn’t stretched too far. Software isn’t a physical thing, so any analogy with building will naturally have limits. Deleting a few source code files is not tantamount to bulldozing a garage and doesn’t have the same sort of relative cost.
I know I’m not an architect, so I wouldn’t try to tell the builder every detail of what to build. What I would do, though, is give him a prioritized list of characteristics that I wanted in the house, and let him use his professional judgment to get as close to those characteristics as the physical limitations of the lot and the budgetary constraints allow. Whether you’re buying an existing house or having one built, you always compromise. Always. There are a few key characteristics you must have in order to be happy in the new home, but most of the details are really flexible, when you come right down to it.
I would expect frequent feedback so that we could be sure we had the same general understanding of what was going on. Generally, though, since he’s the architect and I’m not, I would have to trust that whatever he came up with would be a reasonable approximation of what I needed, and would support as many of the high-priority characteristics as reality might permit. This has to be good enough by definition, since it would be the best realistically-possible outcome. Other outcomes I might imagine to be better would only be dream-smoke, since I would have no additional time or money and the “perfect” structure might not fit on the lot, or at least would only fit I we ripped out all the trees and destroyed the natural contours of the land that were among the reasons I purchased the lot in the first place.
So it is with software, as well. There are key business capabilities to be supported, and we can only do our best to achieve those within the limitations imposed by reality. Frequent feedback and course-correction (the adaptive approach to development) is often the most pragmatic way to get to the best-feasible outcome. In my experience, business stakeholders already know this because they live in the world of profit centers, where they have to adapt to reality every day. Every little thing they try doesn’t work out. They are constantly adapting, throwing out failed ideas and trying new ones, without looking for anyone to blame. They are responsible for revenue generation. It seems to be IT departmental managers who want hard-and-fast requirements and estimates up front. My observation is they think this way because they live in the world of cost centers, where their primary responsibility is to burn down a budget that is given to them by someone else. This single difference leads to fundamentally different mindsets.
Regarding the short-order cook idea, it seems to me that different companies have different relationships to information technology, and that may have something to do with the nature of the work software developers are asked to do. I think there are primary, secondary, and tertiary technology companies. A primary technology company invents new technologies. A tertiary technology company uses technology, but isn’t in the technology business as such. A secondary technology company helps others make effective use of technology. I remember a conversation with one colleague who complained that he didn’t often get any interesting or creative assignments. I described the primary/secondary/tertiary model to him, and suggested that if he wanted creative work he should apply to a company like IBM, Oracle, Microsoft, or Sony-Ericsson. We were working for a bank at the time…a tertiary technology company. Our job, I said to him, was to change the light bulbs, not to invent new and innovative lighting systems. (I don’t work for a bank anymore, by the way, although I do help banks and others make effective use of information technology. Much more satisfying than changing light bulbs.)
Comments on top of comments…
Miss Kitty’s hostile attitude toward others no doubt causes serious problems wherever she works, whether with software engineers or anyone else. Luckily for her it’s always someone else’s fault. She must be a joy to have as a neighbor, too. For a person who admittedly has “no idea what it is like to be a software engineer,” she certainly seems to have a wealth of knowledge about the inner workings of other people’s minds. In lieu of respect, trust, collaboration, compassion, and experience, that skill must come in quite handy for her. Just imagine all the other professions and occupations about which she has the same level of knowledge. The possibilities are endless! I wish her well.
Kent disagrees with the idea that true priorities are transient. I think both perspectives are valid. The difference is in the level of detail we are thinking about. If we consider the business capabilities the company must have in order to meet its objectives, then the true priorities are certainly not transient. If a bank is changing the way its loan origination operation functions, then it definitely needs applications that support the new operation. That business priority will not change, even as the specifics change. Exactly what the applications should look like and which features are more critical to get to market early may change; exactly how a given feature is implemented may change, or may evolve from one release to the next; and so forth. Priorities at that level of detail are transient, or if “transient” isn’t quite the best word, then maybe “subject to change.” Just my 2 cents.
Javier takes issue with definitions. He is quite right…we throw the term “software engineer” around freely, and yet in the US there is no formal requirement for software developers to be certified engineers (in some other countries, that is a requirement). When we stretch the meanings of words like “engineer” and “architect,” we dilute the meaning of the words. When we observe software developers who do not understand and cannot apply engineering principles in their work, and we see that they are labeled “engineers,” what does that say about the occupation in general? It seems to be pretentious at best, disingenuous at worst. I’ve been developing software professionally for 35 years. I’m not an engineer.
On the other hand, I’ve met plenty of certified engineers from other countries who hold masters degrees or higher in computer science and have 10+ years experience writing software who couldn’t write a clean line of code if their lives depended on it. To give credit where it’s due, those individuals are usually pretty adept at Googling for sample code snippets and pasting them into the production code base. That sort of thing doesn’t help the reputation of the term “software engineer” much, either.
Come to think of it, though, it isn’t even universally accepted that software development is an engineering discipline at all. Maybe it’s perfectly okay that we aren’t real engineers (except those of us who decided they liked software better than hardware at some point).
Some commenters had enough spare time on their hands to criticize the author for typos. I’m sure their employers and customers hope that they can do a more effective job of distinguishing the important from the unimportant when they are at work than when they are fooling around on the internet.
Dave Nicolette on June 14th, 2012 at 9:05 am
@Nate – I can only speak from my experience. Yes, we all want to be paid for our work, but in my experience pay isn’t nearly as satisfying as being allowed to create. As I commented earlier, the joy felt when one receives a payraise lasts for a couple of days while excitement over your creation lasts much longer. At a certain point, you will have enough money, but you’ll never get enough of that feeling of creating something new.
Nicholas C. Zakas on June 14th, 2012 at 9:29 am
[...] great article, entitled “The care and feeding of software engineers“, does a pretty good job talking about us software engineers and why we do the things we [...]
The care and feeding of software engineers - Thomas Hunter - Web Development Tutorials and Personal Opinions on June 14th, 2012 at 9:40 am
* Our job is not to say “No”, but to say “OK, but it’ll take this long to do it — Given that, what’s the priority?”
* Scrum supposedly ensures developer focus over a given timeframe, without shifting priorities and with minimal specifications. I am still learning how to best do this.
* Communication across the team is REALLY IMPORTANT.
* Estimating accurately is REALLY HARD. I’m on the verge of telling my team to simply double (or even triple) whatever time-effort number they come up with.
* Where I work now is has much less of the problems you listed above vs. where we both worked last. Webdevs and server-side engineers are encouraged to be part of the design process; there is very little “over the wall” syndrome.
Jim Gourgoutis on June 14th, 2012 at 9:40 am
Javier, I believe your last sentence says it all: “Electrical engineer that has worked as a developer at times in his career”. Please refer to the section above titled “I used to code”, I believe you fall into that category. This is an excellent and accurate article that properly depicts the life of a Software Engineer (Note we aren’t talking about Electrical Engineers). Live long and prosper!
Kerry on June 14th, 2012 at 10:08 am
I’m 52 years old, been coding since I was 22. Great article, very useful insights.
A book from 2002 which validates a lot of what you are saying: Leading Geeks.
http://www.amazon.com/Leading-Geeks-Manage-Deliver-Technology/dp/0787961485
Chris N on June 14th, 2012 at 10:47 am
Great article !! I do agree with all the points you mentioned
Ahsio on June 14th, 2012 at 11:05 am
You my friend are a GENIUS! This is the greatest article on engineering culture and I hope to make it mandatory reading for our entire company. Very well put!
Dennis Quintela on June 14th, 2012 at 11:50 am
Reading this made me think immediately of a great essay by Paul Graham titled ‘Maker’s Schedule, Manager’s Schedule’. (http://www.paulgraham.com/makersschedule.html)
I’m not a software engineer, but I have two as brothers. As a graphic designer for the past three and a half decades I’ve noticed the shift in the workforce from creative specialists, to technical generalists– not just in my own, but in many, many fields.
But in the end it’s the makers and the managers. I think Paul has it right. It’s almost like two different dimensions or worlds. Is it possible to co-exist peacefully and productively?
Rumor has it that some ‘enlightened’ organizations exist out there that actively cultivate and cater to the creative fulfillment of their workforce. This thread would be a great place to hear from such a worker.
Bob on June 14th, 2012 at 12:18 pm
@Bob – that’s a classic article as well. Love it.
Nicholas C. Zakas on June 14th, 2012 at 12:23 pm
What an incredibly accurate and insightful article! As others have said, I feel that this article has been written based on my experiences.
Thanks for the great analogies and phrases!
I especially liked “I don’t care how many women you give me, it still takes nine months to make baby.”
Tell your friend thanks for me.
Neil Opet on June 14th, 2012 at 12:53 pm
First, congratulations for taking your time and creating such a good article with nice insights.
But….
The engineers I’ve met usually cannot say No
Seems strange that you start with engineers that usually say No. In my day to day work I see a lot of engineers that should say No but “we” say yes. Perhaps because:
- the “boss” said so.
- we want to look like the guy that can do everything.
- I’m paid to do this so I cannot say no.
This of course generate a lot of problems. Not being able to say no means:
- Interruptions.
- People pretending they can do your job.
- Continous changes of schedule
In the end: full demotivation.
So you said “yes”, now… what?
The next step is an estimation. The very meaning of the word says that you aren’t talking about an exact measure. It’s just an “estimation”.
The first problem with estimations is that people understand them as final dates. Unless you do something about it. You just said a final date. You said 30 minutes? in 25 I’ll be here with my coffee.
So one of the first thing that can help you here is: you should update your estimations. For the rest of the people to understand that is an approximation, and not a final date, so it can and it will change.
But Why do they change?
That’s another problem. As you said, we do not build IKEA chairs, but we do “brain” work. The more information, the better you can plot your way through the project/issue.
While you cannot know every detail, we fail to realise that we can know a lot with a few questions.
A small summary
We often say yes, when we should be saying no till we give it some time and/or get extra information.
Javier Gonel on June 14th, 2012 at 12:53 pm
It’s Not just an Engineer Flaw. The Planning Fallacy has been shown to affect people in all professions. Here’s a quote from Wikipedia “The planning fallacy is a tendency for people and organizations to underestimate how long they will need to complete a task, even when they have experience of similar tasks over-running.” Apparently it’s normal to do that.
Gary on June 14th, 2012 at 1:40 pm
couldn’t agree more. I’m a product manager and as far as I’m concerned, the products we finally deliver are an end result of our entire team (pm, dev, qe,ui, ui, doc) working very closely together and iterating together from the very beginning . as a PM there’s nothing i like more than an engineer that will geek out on product discussions with me. and the end result is very much influenced by the creative input of all involved.
the least interesting interaction to me is the “short order cook” kind.
kayvaan on June 14th, 2012 at 2:00 pm
Brilliant. Beautiful summary. I will share this many, many times over.
Harry on June 14th, 2012 at 2:29 pm
Well stated and hauntingly familiar…
The scenarios you describe have occurred in some measure in every project I have ever been involved in.
I would like to thank you for providing a clear, concise summary of how we can work more effectively with the managers, designers and analysts that help our projects see the light of day.
Robert on June 14th, 2012 at 4:06 pm
Hey Nicholas,
Just a fantastic post all the way through, you have nailed the plight of the software engineer right on the head.
I digress, but you could show video montages of frustrated engineers and have David Attenborough do the voice over by reading your article and just like that you have a nature program on software engineers
Thanks for posting!
Dylan Oudyk on June 14th, 2012 at 4:56 pm
If I didn’t know I hadn’t written this, I would have thought I wrote it.
Robert Diamond on June 14th, 2012 at 7:01 pm
I cannot tell you how this article just touches every fiber of my being. I’m a Software Engineer, and I face all of these problems every single day. What really makes me dumbfounded is when managers spend the whole day with a customer going over what they want. Then the managers come to us and give us about a few sentences of what the project is about. Then they always go, “so how long do you think it’ll take”. ARE YOU KIDDING ME! It took you guys the whole day going over what’s going to be in a piece of software, then you explain what’s required in a few sentences, and you expect me to come up with how long it’ll take? ARE YOU KIDDING ME! This has happened at every company I’ve worked at. Writing software is a passion, but I’ve come to despise the software industry as a whole. It’s filled with too many ignorant people.
Mark on June 14th, 2012 at 8:25 pm
This is an interesting article, but I think you are wallowing too much in grievances. I am also a software engineer, and find myself in this situation with almost every new task.
My policy is simply to send an email to the customer saying “Because the deadline is 3 weeks from today, I am going to code a single garage, separate from the house. Please contact me by Friday if you don’t agree with this decision.” You would be astonished at how many requirements are thus easily defined! I think you are talking about coders, not engineers. Coders are those experts who love coding so much that they do it in their spare time as well, who have super logical brains, and despise people who don’t. I’m not a coder, although writing code has been part of my job for about 13 years now. I’m an engineer, and to me, coding is just a tool to do the really interesting part of my job, which is to solve the customer’s technical problems, and get paid for it. I am aware that true code monkeys will be despising me for admitting that I get paid for writing code, although it’s not the centre of my universe – says it all, really.
Isabella Jackman on June 14th, 2012 at 11:06 pm
Hi Nicholas,
This was spot on. Seeing people use my software, and find it useful, is the driving force behind my being an engineer. I’ve always thought, though, that software wasn’t done until it had been debugged, so I really appreciate good QA people–good being that they could accurately describe how they generated the bug.
Programmers do get the earned stereotype of saying no. I still say no as a knee-jerk reaction now and then, but not so much as when I first started working as a software engineer.
Reading this article made me feel bad for QA people. While programmers are quick with the “no,” QA people get a bad rap all around. They are the bearer of bad news (bug reports), or the people that delay release (a lot of the worse places I worked would only schedule time for QA and bug revs as an afterthought).
I tried to thank the QA people when they found bugs, since the product would be even better. I imagine for them, even more so than programmers, praise was something very rare.
Thanks for the article. It’s certainly thought provoking.
Tony
LVTony on June 15th, 2012 at 12:28 am
As a couple of posters have alluded to, this excellent article applies more widely than just to Software Engineers. I work as a hardcore Hardware Engineer (including assembly-level code) (and sometimes as a Mechanical Engineer, Technician or Assembler), and have faced some horrible experiences that would illuminate your article, curl your nads and curdle your Mountain Dew(tm).
Among the worst was (really) a demand for daily meetings and hourly status reports with detailed explanation of “why progress is slowing-down.” Another was requirements that all (hardware) Test Procedures conform to, and use, a new Golden-Boy’s logically impossible doc template (“unless the spec [not written yet] specifically includes a parameter [no smoke? complete system crash? overtemp shut-down? loss of user data? violation of mfr's abs max limits?], you are neither permitted to test for it nor to report it”). That one cost the company million$. Worse, the template doc was full of errors that caused a blue-screen if the “wrong” text was entered (‘needed a separate computer just for that doc).
Mis-use of TFS too: “yes the different configurations arrived from the factory for testing in a different order than scheduled; but you are still responsible for making sure the testing of each config meets its individual schedule; that all configs are done within the window for all configs to be done is immaterial: half were done after their scheduled completions!”
I have encountered good managers, and very very bad ones. The worst are the ones who provide their own engineering edicts or schedule estimates: “just add a capacitor or resistor or something: Problem Solved, ten minutes,” “WD-40 will fix it.”
“You say it will take two days? You have ONE, and also, I need you to re-do the power-supply design for 12V instead of 24V, ASAP, Pri1.”
“Why do you design a filter at the A/D input? We are not interested in the 1kHz switcher frequency. Sample (with no input filter) at 10Hz for calculating the battery-life.”
“If you want time-off, you have to file for vacation, even if it IS a weekend.”
And, as a contractor, scheduling meetings at 7:30AM and 6:00 PM, when no overtime-billing is permitted.
Bah! You got me started!
G..K on June 15th, 2012 at 12:33 am
Nice to know I’m not alone…
Peter on June 15th, 2012 at 2:15 am
Me too. That’s all I can think of right now I’m going to send this to so many people in my organization…
Ran Biron on June 15th, 2012 at 2:36 am
[...] A lire! Pourquoi les devs disent toujours non ? Un super article sur comment comprendre et motiver u… : via @tzilliox [...]
La veille du week-end (trentième) | LoïcG on June 15th, 2012 at 3:20 am
Well that was the most refreshing read I’ve had in at least 6 months and probably the most insightful interpretation of what a software developer/engineer actually is in reality.
Like so many others here, this article struck a strong chord with me.
I’d just like to ask the question: is the perception and mis-handling of coding professionals (whether they have degrees or not – lest we forget Bill Gates dropped out of education before he could obtain one) the reason why so many of them (like myself) choose to be freelancers?
The freelance developer has to deal with everything. There’s therefore no option but to be part of the end to end process of problem solving by design, implementation by code. It’s holistic creativity without a boss and where the deadline is more flexible, simply because you can usually factor in that learning curve and generally take the time each project deserves. This in my experience results in a project that is generally successful, which brings the client back for improvements that a developer might already have identified at version 1.
This makes me happy as a dev and small business owner. I get to improve on the work ive already done and get paid for it. For me the money is always a consequence and not the main driving force.
Many thanks for sharing this article with the world.
Next time I have to justify my craft or explain an inevitable time constraint, I’ll be linking here!
Just one final point and I’ll get back to my real job:
Since Google came along I believe everyone has copied and pasted something at one point.
So long as you learn from/adapt what you copy and do so when you get stuck, I think you can still make great things. We’re all learning every day, even the best coder in the world will ‘borrow’. As the saying goes: “Good writers borrow from others, great ones steal.” ..and what’s the point of this open information age if no one benefits from it? The fact that so many licences for great tools are GNU or equivalent is testament to the mentality akin to Steve Wozniak! If you don’t know who that is, feel free to use the open and collaborative Wikipedia to enlighten your brain.
Chris Henry on June 15th, 2012 at 4:20 am
Loved every word of it. Making sure more people get to read this article. I wish this was reddit so I could +1 this.
rlemon on June 15th, 2012 at 7:10 am
Perfect synopsis of the situation which we face, except of course your comments on the money. While money is certainly not the sole motivator it definitely makes a difference in job satisfaction. Above all else I want to feel respected and valued and what I am begin paid plays into that formula. Thanks for a great article.
Ronda on June 15th, 2012 at 7:25 am
Awesome post. You’ve captured it all very well. I would add two things:
1) if your boss is a former “management consultant” or a “suit”, every problem you highlighted becomes worse by at least a factor of 2 (maybe 3 or 4).
2) I hate the cliche’ “money isn’t what motivates developers” because it’s overly-generic and only partially correct. It proliferates a false concept. The difference with software developers is that our primary motive is not money, it’s the stuff you mentioned. Suits, on-the-other-hand, are almost always motivated by money first (power second, resume padding third… then the stuff we care about). That leads to an in balance of both objectives and compensation. The more suit-dominated a company is, the more money gets thrown around (and the more the software sucks). But as long as suits are throwing money around, I want it directed equally in my direction because I’m doing the work that actually creates value rather then simply redistributes it.
Joe on June 15th, 2012 at 8:29 am
Wow this is so true that I could not help making a generic comment about how true this is. Will forward to all my co workers
Rajiv on June 15th, 2012 at 9:32 am
This was a very long but also quite awesome post. I really feel for you, reading this. The best part of it is that you give excellent solutions to the problems laid out! Having said that, I have to admit my honest thoughts are that there is a fair amount of whining in there too. All the others on the team, after all, also have to deal with many of the issues you laid out here: changing priorities, changing design, not getting enough details in the beginning, etc. Project managers and designers deal with this also. I’m sure they get grumpy too, lol, and probably write long blogs about it too. All would benefit from your excellent advice on how to work better together!
GoddessAnonymous on June 15th, 2012 at 9:37 am
Love this article. Now, how do I take this to everyone else at my company and make them understand it?
Evan Meagher on June 15th, 2012 at 9:46 am
@GoddessAnonymous – I’m glad you enjoyed the post and really hope it didn’t come off as whining. I think of whining as irrational blubbering about a situation without analysis or suggestions for improvement. I tried to deliver the facts as I know them in the hopes that it will help others in their jobs. The reason: in my consulting with companies, I frequently find that these issues are not discussed and lead to organizational problems.
You’re right, everyone has work frustrations, and I hope that everyone will take the time to stop and write a long blog post analyzing them and suggesting solutions.
Nicholas C. Zakas on June 15th, 2012 at 9:48 am
Nicolas, your post is awesome but lacking one core main problem. You need to emphasize a section that talks about Code & Run and most businesses treating Devs like a sweat shop meaning they try to churn out as much as possible as FAST as possible and this is a domino effect:
- We hate our jobs because of this
- Family gets affected because we’re constantly running to get stuff done in ridiculous timelines
- We have to fix shit later because of the pile we were forced to code and it’s a pile because the business wanted it done presto so no time to bake in a clean code structure
This is all bullshit how American companies operate. We already have enough stress learning all the new stuff coming out. We don’t just magically pick something up and in 2 seconds for example go code a Metro App for Windows 8 since the customer wants it done tomorrow. It’s crazy how businesses just think we can hack something up in 2 hours and expect hack to be ok when the code is the base/Core of their fucking business.
So my point is, yea SOME devs always say yes to CEO, VP, Dev Mgr, PM to everything and every timeline DICTATED to them but I can tell you I do not. It’s stupid not to be up front even if they don’t like the answer and even if you are risking your job by being “normal” and “reasonable” with the estimate and estimates are just a very vague timeline at best. It does more harm to all if Devs are afraid to tell it how it is when giving estimates or bringing up a problem with maybe how something may go if you do x,y,z and have a team conversation about it than to just sit there and hide everything and act like you can do it however fast the business wants it and with little help.
This has got to stop, mainly this expectation of Code & Run more so compared to Dev pride. The environments we work in are literally sweat shops if you look at it..it’s not that much different. Why should a PM force you in their conversation or body language to basically say yes to their every desire on dates that they come up with or change your mind when they bitch because you gave them 2 days instead of 1 and you know for a fact you need probably 3 days!
Ridiculous. I don’t put up with it…I’ve got a family and my kids need me to come home at night. If an employer wants to slave me to death, good luck, I move on or you fire me…until I find a decent employer who can treat employees right. How are we to be treated like all you are saying when there is no time to look up stuff, learn, etc. because some asshole is breathing down your neck to force and squeeze hack code out of you when they know nothing about management first off and second a lot of times about development. This is why Agile/SCRUM works so well, you don’t have to deal with that bullshit if you are doing true Agile/SCRUM as much lets say. However Agile/SCRUM also dictates some ridiculous paces itself sometimes. So as a whole this is a major problem in America, FAST FAST FAST as possible. How about having some kind of reality here and yes, slowing down a bit even though you THINK you have to run to keep up with competitors. You do not. It will cost you and your staff to run a business this way into the ground eventually.
Dave on June 15th, 2012 at 10:12 am
My boyfriend (who works as a web dev) made me come read this after bitching about my sales manager, my boss, and a client presenting me with a task i knew at stage one was a waste of time, given it would all be subject to change, quite likely entirely, when i’d finished.
I’m actually not a coder, i’m a graphic designer, i spend day in day out making leaflets, business cards, sales brochures, generally everything you’ve ever been handed that you threw in the bin a minute later.
It’s gratifying to know that his job is pretty much identical to mine, at least in terms of process, flow, and random changes at the customers whim midway through a design (tho he likes to remind me that everything he does takes longer). I *wish* the same culture of “you aren’t doing something directly relevant to your current job, so i’ll find you something to do” didn’t exist. People in charge rarely seem to get that creativity does not sprout from nowhere, you need to spend time just looking at what has been done by others, and what is new in your field to refresh your own imagination (the 20% time) not just be shifted straight from project to project with no moment of downtime to refuel. I think my boss is slowly catching on that i work better without him and the sales manager leaning over my keyboard, but it’s taken 11 years. I’d forward this to the both of them, if i thought for a second they would read it.
Adam on June 15th, 2012 at 10:45 am
Thank you.
Sheena on June 15th, 2012 at 1:46 pm
Thus probably goes under “recognition”, but the #1 thing that makes me grumpy is when a salesman sells something, I spend long hours working on it and supporting it, and the salesman gets a vacation on Tahiti and is mentioned by name at the company meetings for how much money he made the company.
A tip for all managers: telling me how much money the thing I’m working on will make the company is not only meaningless, but borderline insulting. It only reminds me how much richer the CEO, the stockholders, and/or the investors are getting off my work; when, when it’s all over, I’ll be making the exact same salary either way.
Yakko Warner on June 15th, 2012 at 1:48 pm
Wow! I have made every single one of these points at one point in time especially recently. I have loved computers and tinkering since I was a young kid. When I finally decided to do this for a living it was like a dream come true. This is a very creative field but it seems more likely that you will be treated like a resource and not a person or a more importantly a creative person. This made my Friday a bit more happy.
Teresa on June 15th, 2012 at 2:00 pm
Your article should be required reading for all IT folk…
(I was interrupted no less than 8 times reading it, so some of the spirit may have been lost on me
Ray on June 15th, 2012 at 3:55 pm
These are true words, thank you for that insightful perspective. Howveer, I must say I enjoy a simple fix request once in a while, half an hour refactoring break to clear your head…
aelg on June 15th, 2012 at 6:12 pm
[...] is the article – The care and feeding of software engineers (or, why engineers are grumpy) Like this:LikeBe the first to like this. Leave a [...]
Why Software Engineers are Grumpy? « Ashik’s IT Thoughts on June 15th, 2012 at 6:40 pm
Absolutely awesome article! Thanks Nicholas!
Bernhard on June 15th, 2012 at 11:24 pm
Absolutely brilliant! Your insights, or ability to put in print what is actually happening, is terrific. Thank you!
Amy on June 16th, 2012 at 12:18 am
[...] Impresionante artículo de Nicholas Zakas sobre los ingenieros de software: Es largo, bastante largo, pero por favor, que lo lea todo el mundo: Ingenieros, diseñadores y managers (técnicos, de producto, de lo que sea). Demasiados puntos de los que comenta los he o vivido o visto suceder. Por supuesto es desde nuestro punto de vista, pero tiene muchísimas verdades como templos. [...]
Noticias 16-06-2012 - La Web de Programación on June 16th, 2012 at 2:28 am
First off, this is an absolutely brilliant article, hitting it right on the spot. It is an unbiased view into the mindset and typical frustrations faced by programmers. Secondly, to Miss Kitty, this article is not about complaining and whining. It had just provided you with the understanding and/or clues on how to better manage and work with the engineers. Finally, having spent many years in software within multiple industry classes and company sizes, I must also say that through my personal experiences and observations, the above article is spot on in reflecting the programmers who are motivated and passionate of their crafts. However, its a different game when dealing with so-called ‘career programmer’ who are in the industry because of the view that it may provide a stable path and pay, which seems to be quite prevalent within ‘outsourcing’ world. I have come across such teams of engineers who couldn’t be bothered, and are emotionless towards such impacts on their daily routines.
Han on June 16th, 2012 at 2:45 am
Hi Nicholas,
Thanks for this this is indeed true words and does provide a very insightful perspective on how software engineers tick. We are indeed are creators, not builders. When we been treated as builder, we either keep quiet or get very very grumpy.
After reading your article, I feel more and more relieve and some how our plight had been written out in an article.
Carter on June 16th, 2012 at 3:28 am
Great article. I love being a software engineer and nothing makes me happier than using my brain to solve coding problems, alas there are other things to deal with. You forgot the grumpiness that comes from testers raising a million defects when absolutely none of the defects raised are functional issues and are just formatting when you’ve specifically stated in release notes that formatting hasn’t been broached yet and to just test the functionality, or a spec issue where you’ve written something to work or be worded the right way after speaking with the BA and the testers can’t use their common sense to realise that what they’re seeing is actually right and the spec was wrong. Arrggh…. or a tester will interrupt you with an inane question, forcing removal of headphones and totally interrupting your train of thought. I hate my grumpy self, 99% of the time I’m happy, fun and great to be around, but testers seriously bring out the worst grumpiness ever. Don’t they realise this is your baby they’re ripping to shreds? That you’ve spent ages making it look nice and work correctly, but because it doesn’t quite match what someone who doesn’t write code has written in a requirements document it can’t possibly be right. Okay, rant over.
Mark on June 16th, 2012 at 3:59 am
Great article. I think the title is a bit misleading and would put off some that should otherwise read it (the first bit about being grumpy sounds a bit confrontational, which is obviously not what the article is about, but easy for someone to read a few paragraphs and then dismiss it.)
John Pile on June 16th, 2012 at 11:49 am
Incredible.
You must be magician, every word in this is so true. I never read such great article about us.
Thank you very much!
Pooky on June 16th, 2012 at 2:56 pm
I feel this article hits the nail on the head however the only point I’d disagree with is this right here. While some programmers might have fragile egos I believe a large number of under estimations comes from the fact that if you do give too long of an estimate you will lose business.
As someone who has been a contractor in the software development world you tend to learn that people want it “fast”. If you give them an actual estimation (or even a slightly over-estimate) often times they’ll go to someone else who can promise to deliver it twice as fast. Whether or not their alternative developer(s) can deliver the project within that time frame is another case all together. However I feel that as a developer we are sometimes forced into giving these poor estimations as a way to retain clients or appease management. I think what it really comes down to is its easier to tell the client/management “We’re going to need more time” after you already have their business/investment as opposed to approaching them with a legitimate estimation that might cause them to look elsewhere.
I think what it really comes down to is that old adage: “You can have your software Fast, Good, or Cheap. Pick two”. It seems these days people (clients or management) want all three and then complain when a project suffers because of it.
directionalpad on June 16th, 2012 at 9:52 pm
Good words of wisdom and insight here.
I’ve always found it interesting how myself and other programmers will get so upset about changes. From a logical and external viewpoint, what’s the big deal? You come to work, you write code, you get paid. If the code never gets used, so what? You still get paid. If you have to rewrite a bunch of it, big deal, you get paid to re-write it. But as engineers, we react like someone just walked into our homes and ripped the food out of our kids’ mouths.
I think managers do not always realize how personally attached we are to the work we do. It’s not an assembly line. We put our souls into the code and we are proud of it when it’s done (usually). A big change order is a massive invalidation of that and gets a visceral response.
Keith Peters on June 17th, 2012 at 5:45 am
You have just described my week. I work in France and the process and the issues are 100% EXACTLY the same. I’m very surprised that it’s the same everywhere. I would also add that when we say no, sometimes we actually really enjoy saying no, don’t we? I was happy to read your post, finally I’m not alone in the universe. Thanks
Elodie on June 17th, 2012 at 10:02 am
[...] The care and feeding of software engineers [...]
Sunday Selection 2012-06-17 « The ByteBaker on June 17th, 2012 at 12:01 pm
I’m a professional designer turn professional software engineer. This article speaks to both sides of me. I’m not a designer anymore because I decided engineering simply pays more, and I need to support myself and family. I have around 6 years professional design experience, and a BFA. Does that mean because now I am a professional software engineer that my design opinion is fodder? Apparently is does to most project managers, but funny thing is, not to the actual designers who value my opinion. As for software engineering, this is the most ungratifying job ever.
I have always said that a software engineer gets the most attention when something goes wrong with bugs, but never when everything is built well and functional.
James Isaacs on June 17th, 2012 at 4:18 pm
As someone who has been working as an “Associate Software Engineer” as it was stated in my contract with a web development agency, I can really agree that most of the time, we don’t really apply many engineering processes. So if we are engineers in name only, it’s usually because reasons related to time and money on the management side. To most employees, engineers are seen as money sinks that do some magic they don’t quite understand but they need for the business. On the other hand, the managers and marketers are seen as the profit centers.
I’m also curious to know as to whether this problem is mostly inherent with software only, and if other types of engineers, such as electrical, mechanical, civil, etc. are given more leeway and consideration to designing solutions to their technical problems. In other words, actual engineering! Some of them joke about software engineers not being “true engineers” and to some extent, at least in the real world (because it’s so different from academia), that is accurate.
Chris on June 17th, 2012 at 5:37 pm
I am amazed at how well you captured the mind of the Software Engineer here. Well done! I think I will send a copy of this article to all of my managers, past and present.
Shawn on June 17th, 2012 at 9:47 pm
I’m a mechanical engineer, and the same thing happens here with arquitects, managers, clients, etc, etc….
I think it’s just the way it is…
Ricardo Perry on June 18th, 2012 at 2:27 am
[...] engineers are often very attached to their code. The code is their baby. They believe it is perfect. They don’t want it to grow too fast. They won’t let others [...]
Your Code Is (Not) Your Baby | The soft nature of software on June 18th, 2012 at 3:06 am
Thank you for writing this up. We’ll read through it and let you know.
Cem Onur on June 18th, 2012 at 6:21 am
[...] of a database inside a browser. But producing novel software requires the programmer to act as creator. While your programming classes might teach you how to cook an egg (metaphorically speaking), they [...]
On the quality of academic software on June 18th, 2012 at 7:28 am
Great article!
Mark on June 18th, 2012 at 11:39 am
Thank you for the brilliant article and for the every day working hard to make ideas come true from.
Thank you from all designers. We contribute as much as possible into projects but at the end all we can do is just make a proposal. And then coordinated effort from with you helps to make the real things happen. I’m looking for a ways to enhance the communication between team members. Thank you for the insights.
zettaua on June 18th, 2012 at 1:38 pm
Great article! I’ve been writing software full-time for over 30 years — nothing changes, these insights are the same today as they were 30 years ago.
Stuart Rackham on June 18th, 2012 at 2:20 pm
You hit the nail on the head with this, thank you for taking the time to write it.
Nick Winfield on June 19th, 2012 at 6:14 am
Greetings From Greece!
Your article is really great and (sadly) so true…
Unfortunately, the only people that’ll spend some time reading it and will really understand what you are talking about are the engineers themselves…
(All the others are in a meeting…)
Pavlos Chrisochoidis on June 19th, 2012 at 6:27 am
I think you’ve nailed the *environment* in which programmers work right on the head. It’s quite possibly the best description of a typical “coders work environment” I’ve come across. The house analogy is perfect.
Your description of engineers themselves I found less in line with myself. For example, I have little or no interest in things like hack days & hack weeks. I find them riddled with a competitive spirit which is counter to the creative nature of how I approach writing code. I also have no interest in rewards for my work (save reasonable financial compensation), so “most likely to be shipped” awards, etc, would feel silly and much like an “employee of the month award” (http://www.joelonsoftware.com/articles/fog0000000070.html has some great commentary on why these are bad for devs). And while yes, there are devs out there who fail to take time off, that’s less a characteristic of a developer and more a general personality trait of some people. I have no issues identifying when I need to decharge and taking some vacation days to do so, and have many developer friends who are the same.
All-in-all though, amazing article, really enjoyed it.
Adam Parkin on June 19th, 2012 at 8:12 am
[...] Why Engineers Become Grumpy Nicholas Zakas tackles the topic of why engineers seem grumpy to business folks and how to get the best out of them. Engineers are not just builders they are creators too and must be involved in the creative process and be recognized for their achievements. [...]
IT Operations News Roundup – June 11th to 17th | Web Performance Monitoring and Optimization on June 19th, 2012 at 11:08 am
Amen brother.
Randy B on June 19th, 2012 at 12:24 pm
Completely agree with everything here with one caveat:
You mention that money is not a motivator for software engineers, and that’s very true… unless there’s not enough of it. There’s a lot of just-out-of-college grads out there that are getting paid peanuts for their first “real programming job” and that can quickly lead to frustration, burn out, and worse. More accurate would be to say that money doesn’t matter as long as the paycheck is competitive. As long as we don’t feel like we’re getting screwed, money is of little concern. Joel Splosky enunciates this far nicer than I ever could when talking about how to hire developers: http://www.joelonsoftware.com/articles/fog0000000050.html
Also, Please note: Just because money isn’t our primary motivator doesn’t give you permission to skip out on things like bonuses and raises once in a while!
Brandon Jones on June 19th, 2012 at 4:01 pm
Your profiling (for lack of a better word) fits to the general American populace and not just software engineers/developers. Work on a multi-disciplinary projects and you will see same of MEs and EEs. Work in the hospital and you will see same from Drs. – nothing new here I say.
ade on June 20th, 2012 at 7:27 am
[...] my, another thing on the software engineering…this time, it’s someone else who’s been thinking about it. Something in the air? Cards on the table, software engineers [...]
House of Eratosthenes on June 20th, 2012 at 12:37 pm
Absolutely true! Thanks for your wonderful analysis and description of our feelings!
Nicola on June 20th, 2012 at 2:44 pm
Brilliant! My manifesto.
Martin on June 20th, 2012 at 3:21 pm
Let me add my small voice to the existing chorus. Thank you for taking the time to enunciate what so many of us (clearly) feel, experience and live. It is my ongoing struggle to convey this message within my own organization, and it seems you have provided me with some excellent ammunition. Cheers from your mates in Australia
Sebastian Urban on June 20th, 2012 at 3:44 pm
[...] The care and feeding of software engineers (or, why engineers are grumpy) | NCZOnline Reply With Quote [...]
[INTJ] Random Information of the Week - Page 49 on June 21st, 2012 at 12:02 am
About the well-beeing of software-engineers…
It’s a real great write-up about the mindset of software-engineers and on how to keep them happy. I know this is a lot to read but it’s worth every second. This is the very first text on this where I could sign every single statement. Whenever Nichol…
Wicket Game on June 21st, 2012 at 1:07 am
Thanks! You made into words what’s on the mind of many developers I know (and most certainly on mine). Great article, absolutely worth the time spent reading.
David H. on June 21st, 2012 at 1:14 am
[...] ???????? ????????? dou.ua ? ????? ?????? ?? ?????? The care and feeding of software engineers. ???????? ?? ????? ??????????, ?????? ?????? ?? ????? [...]
? ?????? "????????? ? ???? ?? ??????????????" - ???? ?????? ???????? on June 21st, 2012 at 2:23 am
[...] ??????? ?????? The care and feeding of software engineers (or, why engineers are grumpy) ???????????? ?? ?????. ??????? [...]
?????????? kvarkson'a | 20 ???? / ??????, WP8! on June 21st, 2012 at 2:41 am
[...] The care and feeding of software engineers (or, why engineers are grumpy) | NCZOnline [...]
Linkage: June 6th, 2012 to June 21st, 2012 | ben lowery on June 21st, 2012 at 9:00 am
[...] » à la moindre occasion (sauf pour les pauses café/clopes). Alors, pourquoi est-il si méchant ? Des indices ici (attention, c’est en anglais et assez long, mais TRÈS pertinent) ou dans les billets qui [...]
[MMIT] Vocabulaire « kerrubin's blog on June 21st, 2012 at 11:25 am
I dunno; I read the above and I find it radiates an incredible sense of entitlement.
I’m a software engineer; have been one all my life. Two years I took the plunge and left my cushy job at a big company to co-found a tech startup with a buddy who’s also a software engineer. My biggest challenge so far? Not the technology, not the fund-raising, not product-market fit, none of those. My biggest challenge is to consistently get the most out of my team. And the biggest problem I have is that the software engineers I work with are all a bunch of entitled prima donnas. I didn’t realize this when I was one of them; now that I’m on the other side of the table and actually responsible for my company’s ultimate success or failure, I see it all the time.
Seriously. Everyone is like “me, me, me” all the time. What can the company do for me? What awesome perks and freebies can the company offer me? How much salary / stock options can you give me? And so on and so forth.
I’ve got no problem with paying for talent; my first few hires collectively own a huge chunk of the company *and* are paid an above-market wage. I’ve got no problem with making the office an awesome place to work with lots of benefits; I believe that’s the best way to maximize productivity and keep everyone happy. I’ve got no problem with sharing information, with planning carefully, with setting reasonable deadlines, with not pressuring people to say yes, with all the things you recommend. But I do have severe issues with people who spend all their time whining about how unappreciated they are; most of these people don’t have the slightest clue how damn lucky they are to be where they are.
It’s entirely a consequence of supply-demand. We’re in a lousy economy where layoffs are common and wages are stagnant across most industries. But great or even modestly good software engineers are still in short supply and heavy demand. So employers cave in to their every whim.
The above article (and especially the flood of adulatory comments after it) encapsulates this way of thinking. People, get a grip. Everyone’s underappreciated. Everybody gets crapped on from above. Everybody thinks they deserve better. The world is like that. Grow up.
Oh, and to all the commenters who think this article speaks to their innermost thoughts — please. The article merely flatters your idealized notions of who you are. Like horoscopes and astrology: cleverly framed compliments go a long way.
Startup Coder on June 21st, 2012 at 9:00 pm
This is exactly the same for screenwriters.
And I do both.
Bugger.
Steve Turnbull (@adaddinsane) on June 22nd, 2012 at 3:45 am
“Computer science programs aren’t about preparing you for the tasks you’ll face in industry. They’re about giving you conceptual knowledge of a wide range of topics so that you’re not blindsided when you find them in your work. You learn about variables, functions, and objects, because those are things you’ll encounter all the time. You learn about databases and queries though the normal forms you learn are practically useless. You spend an inordinate amount of time on sorting algorithms and data structures, all of which are abstracted away from you when writing code professionally. In short, computer science programs review solutions to problems that you’ll never need to solve on your own when coding professionally. If I need to sort something these days, I call the sort() method. If I need a queue or a linked list, I use the implementation that’s native to the language I’m using. These are all solved problems.”
There is a saying that general are prone to trying to fight the previous war. This also seems to be true of CS courses, in my experience. I have the good fortune to be a physics grad, so when I started in IT (or DP as it was then called), I didn’t have a lot of interesting-but-useless stuff to unlearn.
Marc Wilson on June 22nd, 2012 at 3:50 am
GeneralS, dammit!
Marc Wilson on June 22nd, 2012 at 3:50 am
@Startup Coder – It’s too bad that you read this article and looked at it as a description of a problem rather than a way to understand your engineers and get the most out of them.
Nicholas C. Zakas on June 22nd, 2012 at 8:23 am
I’m not religious but… AMEN brother!!! The entire article is spot on…
Marko Mijuskovic on June 22nd, 2012 at 8:39 am
[...] recommend anyone working with FE engineers to read both that article as well as his other post on working with software engineers. He briefly touches on some of the frustrations FE’s deal with as they try to break into an [...]
The State of FE Interviews | mobicrave on June 22nd, 2012 at 2:34 pm
Nicholas, you’re awesome! So straight to the point, as you are talking about so true things software engineers usually keep inside.
Nik Sumeiko on June 23rd, 2012 at 1:51 am
You said it best when you said there is short supply and high demand.
Unfortunately @StartupCoder is correct this short supply has inflated our egos and allowed for you to describe the behavior while never actually apologizing for the behavior. “It’s just the way we are”
In a company there is money to be expensed on the engineer and this expense should be lower than the revenue the engineer’s product produces. Unfortunately many engineers are more concerned about their “interruption schedule” and less concerned with how they get paid.
It’s a tricky balance (I was an engineer for 10 years and then moved into the business side of the company) This is when I noticed how blind I was to the cost of my entitled behavior.
I love the article and agree with the description. This article falls apart when you get all of what you described in your engineer except it’s more often poor quality.
Your article should state this is a description of good engineers, or engineers that produce quality work. Because if you are reading through this and thinking about a bad engineer. It reads as if engineers are entitled brats.
Again, great article.
Rob on June 23rd, 2012 at 8:07 pm
To the point, every word … Thanks
Erich on June 24th, 2012 at 4:45 am
So what can software dev’s do? This article is completely re-active to our environment.
What can be done within our control to manage the insanity?
David Halonen on June 24th, 2012 at 12:46 pm
[...] off topic, but I would recommend to any developer or anyone working with a developer, is reading the article about why software engineers are grumpy by Nicholas C. Zakas. You’d think he was a carpenter with the many different nails he hits on [...]
Overhaulin’ | The Basement Kids on June 24th, 2012 at 2:55 pm
Thanks for that awesome post. I just mailed the link to all of my colleagues. There is so much truth in it. The only part I disagree with, is when you say we are ok with shipping something good instead of something great.
I think the problem is, that we would like to do something great but all the changes in progress while the deadline stays the same leads to just a good project with – often – way to much features in it that nobody can do great in that – often short – period of time!
Michael on June 25th, 2012 at 2:05 am
Well said !! Every word said, true !! Im 20 and I already feel like this !!
Brenden on June 25th, 2012 at 9:23 am
Leave a Comment
Comments are automatically closed after 14 days.