Hacker News Reader

Comment by dvt | Hacker News Reader

For those just skimming, here are the top 10 reasons for software developer unhappiness, according to the paper:

   1. Being stuck in problem solving
   2. Time pressure
   3. Bad code quality and coding practice
   4. Under-performing colleague
   5. Feel inadequate with work
   6. Mundane or repetitive task
   7. Unexplained broken code
   8. Bad decision making
   9. Imposed limitation on development
   10. Personal issues – not work related

I've dealt with most of these, and I think they betray the mantra of the "modern" software engineer: push features fast. Code quality, adequate explanations, proper planning, and lenient time tables are an afterthought.

View on HN

As a counter-point, another important reason for developer unhappiness is to put in lots of work and have nothing to show for it. Case in point, a company I worked for had so much internal politics we never got around to releasing anything worthwhile and it was the most demoralizing experience I ever had, leading to a burnout.

There should be healthy balance of releasing fast and cleaner codebase. That balance changes based on the team size (1 vs 10 vs 100) and developer experience (the more experienced you are, more effortless it is to write clean code) .

I have an experience very much related to this, which is to develop for a platform I cannot use.

A couple clients in recent years have hired me to develop the backend system(s) for clients that were meant to be built for Android and IOS.

Somewhere down the line, after I'd already been well invested, these projects dropped their intention to develop for Android and thus I was stuck working on the backed for an application I had no reasonable means to use everyday. Sure, I have an iphone for development, but my day-to-day phone is an Android.

Over time it gets harder to remain interested in a project I can't personally use. It's not that I can't fill my day with interesting work, since my portion isn't specific to the client platform, it's just that I can't show it off when I'm not working on it.

Because this has happened a couple times already, I've started ensuring there will at least be a web-client available before I sign onto the project.

As a software consultant, I am rarely the target user on any of the software I develop. Occasionally, this means integrating with platforms or systems I do not personally like. I derive satisfaction from from crafting a high-quality experience for the user that solves their problems. At the end of the day, whether I use the system or not, I can take pride in a job well done.

I've found that sometimes, the difference between a negative and positive situation is just the outlook.

While this is true, sometimes you work on a very large project, the end goal of which you will never see and don't really understand. The abstractness of the work you are doing can be challenging for people who like to be excited about the end product.

For instance, a while ago, I was working on a large industrial project.

Between me and the customer were a layer of business analysts who figured out what the system did, and a layer of systems engineers who worked out the specifics of the system in terms of components with interfaces, and logic flow charts for what those components did in different situations.

For one assignment, I needed to make a value returned by a webservice change when a GPIO was toggled to indicate a button had been pressed. I didn't know what the button did, or what the result meant, and communication with the systems engineers far away was through JIRA tickets. I didn't even ask because the management didn't like off topic comments on the tickets. I think it was a custom feature for an oil tanker, but who knows what I made...

While that way of working was very productive, and produced reliable software built to validated designs - with lovely code because we could really focus on it - it was really hard for me personally to feel any passion there.

>While that way of working was very productive

I doubt that. You may have delivered flawless code to a specification, but who knows if most of it even mattered, the tings that did actually just did a half-arsed job, and everything just marginally lived up to the expectations?

I work on fairly large systems where we have 50 teams (or more, I don't even know) and it's hugely inefficient. Asking the right question at the right occasion can save millions, although it's more likely that they are asked to late when it's just embarrassing at best.

For me it's also important that I can use my skills to make a hobby project to show myself or my friends.

I don't want to be a software tester, because no amount of testing will produce a fun little game or a screensaver.

I don't want to be a devops, because I don't need 60_000 servers at home.

> quality, adequate explanations, proper planning, and lenient time tables are an afterthought.

This is par for every activity involving humans. The problems with devs is they think they cant "control" it better because most of their life experience of "wins" comes from controlling a controllable machine. Obviously when applying it to ppl it all breaks down. Most other profession in the real world who really have no experience of that level of control on anything learn control is always negotiated involving patience which most dev's don't really have to learn leading to all kinds of misguided notions and solutions to real world problems.

Number 2 through 10 I agree with you. Number 1's presence on the list strikes me as evidence that there exist legions of people in this line of work who simply do not belong here. "Being stuck in problem solving" IMHO is a veritable source of professional happiness, not a detraction from it, among the best developers I know.

I don't think being stuck is a source of professional happiness but getting through it and out the other side. It's great to look back in hindsight at how much a situation sucked and how you pulled through. This applies to all sorts of things.

I think you need to be able to enjoy problem solving though even if sometimes mid-process you feel awful.

Look, people are motivated by different things. Some people are motivated by unanswered questions. Some people are motivated by doing a good job. Some people are motivated by the impact they have on others' lives.

Any of these people can solve problems in programming, and they often all do. It's naive to assume your entire team is motivated by the same thing as you. Furthermore, if you're building a team, you want diversity of motivation because it leads to diversity of viewpoints. Programmers who are motivated by people drive us to make usable software and not just to "solve the problem." Programmers who are motivated by quality challenge us to improve test coverage and keep our documentation clean.

If you look at the composition of a diverse engineering team, you might notice that many of them are motivated to solve problems for different reasons.

Programming isn't done in a vacuum, and our job isn't just to crap out solutions to hard problems. We don't work in a vacuum. Our solutions have to be robust, and they have to actually help people. Having a diversity of viewpoints on your team can help you ensure those boxes are checked.

>"Being stuck in problem solving" IMHO is a veritable source of professional happiness

I agree, but it's because the reward is so great. I would imagine it's a different feeling if I was fixing someone else's (say offshore team) bugs all day.

I suspect they mean interrupt bug fixing. If you spend all your time on interrupt tasks it's possible you'll eventually get bored.

It's why people complain about the issues that technical debt brings about.

The paper clarifies that this means being unable to reach a solution, as in, you can't figure it out. You've hit a brick wall. Perhaps your intellect is insufficient or maybe there is no solution, but you're definitely not smart enough to know the difference. That's what's instilling unhappiness.

> "Being stuck in problem solving" IMHO is a veritable source of professional happiness, not a detraction from it, among the best developers I know.

Depends on the problem being solved. Debugging platform or OS problems are a minefield of frustration.

Some problems presented to developers are also very far afield from their strengths and interests, like UI and UX, and so also might be of little real interest despite being important problems.

My read on the quote is the problem comes from the "being stuck" part, not the "problem solving" part.

For example, finding a corner case bug in a library you rely on is generally unpleasant. Sure, part of problem solving may involve either fixing it, working around it, or choosing another library. Before choosing an option, it makes sense to weigh the costs and benefits.

To make a long story short, if enough things pile up at the same time, it can feels unsatisfying because less new user-facing benefit is being created.

One solution, if it works for you, is to take a balanced view of productivity means; namely, a blend of short- and long-term value.

I see #1 more about people developing against ill-defined visions, problem statements, or requirements.

I've often seen situations where developers are told, "solve this problem" without being told the context or even success criteria. They then spend inordinate amounts of time iterating without clearly knowing when it's "good enough" to stop and release.

I love #1, I just find that it never comes without #2. Problem solving is great, problem solving on deadline is much less relaxing.

I think it depends on what we define as "problem solving". If we're talking about the problems that come with actually doing what you mean to do, sure. If we're talking about working around the problems with your software stack that don't actually relate to the end goal, then I'd have to say no.

That struck me as odd, too. A software developer complaining about being "stuck in problem solving" is like a taxi driver complaining about being stuck driving a car.

Depends. If you're stuck figuring out why your from-scratch Haskell app is returning incorrect results, sure. If you're stuck figuring out why the 50K line globals-everywhere VB6-SharePoint connector DLL you inherited is randomly disconnecting, when it's only a tiny but necessary thing holding you up from the meat of your project, and you need to jump through weeks of political/bureaucratic hoops to access the code, that's something else.

http://imgur.com/nt0YEfs

Thanks, I think the frequency numbers are important to know how different the issues are. The paper is quite a bit to digest but this is probably what most people who click the link are really after.

I would use the table to summarize even further: Many problems are self derived or due to (lack of good) process.

And going further I'd say that even the process part is self derived. If you ask a programmer, he'll often say he hates process, meetings, and decisions where he wasn't in the majority (the last one only indirectly). But he also loves the results of process: quality, aligned decision making, people in other departments considering his previous work on a topic.

The thing with self derived problems is that you can't do much from the outside beside trying to show with examples and experiences that other ways are possible.

Last but not least I personally feel that if you mostly or only have self derived problems left you belong to the happiest group of people on the planet. Sadly human nature does not make us happy if we get everything we want. We're still relatively unhappy.

> 10. Personal issues – not work related

That's sort of any job. I must admit though, I've found it especially debilitating in software development. When I was a plongeur/dishie, I could usually work through my issues, but with software development, my problems in life become intrusive thoughts, that constantly attack me through the day, ruining my thought and problem solving process.

My main point of dissatisfaction with being a developer is actually the lack of human contact. Spending 7 hours a day with nothing but a computer for company is pretty soul draining. I guess it's all about balance though, so to balance it out, often I don't even touch a computer when I get home, my Macbook stays in my bag until the next day. At the same time, I hate meetings, so I really don't know what the solution is.

The solution is to move into a technical but client-facing role. Presales Engineering and Professional Services are great ways to be hands-on, but also tie your work directly to human interaction and business problems.

What is it that you hate about meetings? There can be lots of meetings in presales work, but they're not the same kinds of meetings.

Maybe you could try to find a company or team where there is more teamwork, maybe some truly agile team. Most projects I worked on were not the lonely type - you would be closely and daily cooperating with other people. The issue was the opposite e.g. how to organize it so that there are big enough uninterrupted chunks of time for concentrated work. You might also seek projects that are tailored for concrete customers - you have to communicate about requirements either with customer directly or with analyst. If you have to stare 7 hours a day into monitor, then it means other people are shielding you from all that communication - it is not always like that.

Even more extroverted team might help - other extroverts will do the human contact thing even if there is no practical reason for it.

>My main point of dissatisfaction with being a developer is actually the lack of human contact. Spending 7 hours a day with nothing but a computer for company is pretty soul draining.

That's my favorite part.

as a software developer it really makes me unhappy that this list goes from 1-10 and not from 0-9 ;)

Actually, it should go to 11.

Not all is like that. Julia numbers from 1

Luckily not all languages start from 0.

> Code quality, adequate explanations, proper planning, and lenient time tables are an afterthought.

Can anyone recommend reading material for a founder who wants to get these things right from the start? Is there a definitive guide to creating an environment where engineers can thrive?

The Clean Coder is a good guide for individual engineers, but I don't know one for managers.

Check out the book Lean Thinking.

Besides the books recommended below, check out Peopleware if you haven't already, as well as Joel On Software (skim the blog list to only read the ones related to creating a good work environment).

The Mythical Man Month. I've worked on at least 3 projects that went disastrously wrong and could have been fixed if the manager read that book.

Just one simple advise: sell software as if it were hardware.

If you have it in store, you sell it, as it is. If you don't have it in store, you don't sell it. You can inform potential customers about next foreseen delivery, but do not act as if you _knew_ next delivery date.

Just realise how absurd it is to plan a fixed time for tests: either it works, and the tests will run smoothly the first time, or it doesn't work, and you can't know when it will work. If you knew when it will work, than you'd have understood which defects it has, which means that you'd have had it right on the first time.

If you're a founder, I'd suggest Peopleware and have your engineering and product leaders read The Mythical Man Month

The key is effective product management, which can then lead to effective project management. Specifically, someone needs to know what the product is and where the product is going (road map). Often the product is at the mercy of the loudest sales person, demanding the feature to make their sale. SalesPersonX needs FeatureY to close a $50,000 deal, when CustomerA, CustomerB, and CustomerC have all requested ImprovementD, maybe they'll renew without it, maybe not.

Someone needs to make this call: prioritize ImprovementD or FeatureY. Maybe they can both get done this year, maybe not. It's a business decision, either keep current customer happy or drive for sales. Usually SalesPersonX knows RockstarZ's number and calls him directly. RockstarZ get's burned out from the constant pressure and quits.

So, someone needs to be gathering feedback from customers and prospects, build a roadmap, then project management can concentrate on delivering features.

I have worked at one company that got this right and it was a joy. I didn't realize it at the time, but I've since come to regret leaving there.

Edit; I just realized OP asked for reading material, I opined instead. Sorry, leaving this here anyway

As physical books, 'Becoming a Technical Leader', 'Quality Software Management, vols 1-4' and others condensed Jerry Weinberg's experiences as a software developer, manager, and consultant down to practical, thoughtful suggestions for managing software projects by managing yourself and others. He's now bundled the writing as the 'Quality Software' e-book bundle [0]. One stop shopping for a lifetime's worth of suggestions.

I'd add, as others have or will, 'Peopleware', 'The Mythical Man Month', 'Code Complete', and 'Making Software', but Weinberg not only presents information and tells stories, he gives practical suggestions on how to 'check your work', adapted to your situation.

[0] https://leanpub.com/b/qualitysoftware

You might like this reading list I put together towards creating and sustaining High Performance Organizations:

https://github.com/pdfernhout/High-Performance-Organizations...

Besides the books others have mentioned (peopleware and mythical man month should be required reading for all managers in my opinion), I would also suggest thinking about the following:

make sure you align rewards with the results you want: if you talk about code quality and so on, however you incentivize your execs/manager for "ship quickly and fix later", that's what will happen.

When interviewing all your managers/execs ask them "assume your team leads told you that feature X will take Y months to develop, and I told you that for business reasons we need to deliver it in Y * 0.85 months, what would you do" and hire/nohire depending on how you feel about their answer and how it maps to the books above.

Make sure that if you have a deadline you are flexible on deliverables, there is nothing worse as an engineer than being asked to estimate how long something will take, and then be told that the delivery is fixed anyways. At the same time if you ask for a ballpark estimate, don't then assume your engineers will hit that 99% of the time and bet significant marketing/sales dollars on it.

Some engineers will thrive in environments where customer-is-first and backwards-compatibility is king, where code quality and cleanness are prioritized and code written lives a long life. Other engineers will find that stifling and instead will thrive in a write-fast-and-throw-away environment, make sure you assign each type of engineer to the right teams.

And finally make sure that your company culture is aligned with what you want to achieve: some engineers will thrive in a private-offices/business-is-business environment, others instead will prefer a open-office/work-is-gamified place, hire accordingly.

The problem with The Mythical Man Month is that it contains brilliant observations about software development in general, as well as brilliant observations about developing huge mainframe operative systems at IBM in the 70s.

It's hard for most non-professionals to tell what's what.

I would have liked to write a readers guide or something, but I don't think it'd be as good...

I think you could argue in favour of Peopleware as the "practical" complement for MMM.

Although I'd be curious to hear of any recent books that hit the level of these two.

Should you ask people here? I think it's better to ask this question of actual entrepreneurs than engineers. I wonder if there's any successful startup (assuming you're not hoping to build a lifestyle business) that got there without code debt.

I think the hard part is the search for the product that solves problems. Not technical debt.

I'd add very long hours sat (or even stood) at a desk. Coding on the beach is less depressing.

I've never felt very productive doing any programming outside. Is that just me? I'd rather be doing something else if I'm outside.

Same here. I've tried the outside thing and I think I'm just far more productive and far happier if I keep my outside time free of work.

And there's the fact that my desk is set up to be comfortable, protect against RSI, and have everything I need available at hand. Just sitting back down brings back where I was the previous day.

I like having talking meetings outside. But programming? Never again.

> I've never felt very productive doing any programming outside. Is that just me?

Depends on your personal history I'd say. If you spend years working from home, with little outside interaction in the day to day, productivity truly suffers. Changing your environment can be a huge productivity booster.

I simply can't program with a laptop in my lap without my hands/back starting to hurt immediately. I'd love to work from the beach but I really need an ergonomic setup to get any real work done.

Certain types of work I can do by the pool or in a loud cafe. Mainly expository work like fleshing out a schema or writing doc / emails - where having external inputs guides my internal thought processes.

Implementing designs, for me requires zoning as much as possible. Desks are good for this (if open-style office, headsets with downtempo playing or preferably fewer colleagues around is best).

I'd never take non-hardened gear like a laptop to a beach... if I'm at the beach I'm there to have fun not work.

I really like coding in my garden. I enjoy videoconferencing in my garden even more.

This. I dont mind meetings cause theyre a nice break from standing in one place staring at a screen for many consecutive hours every day...

The only time I notice my surroundings is when 1) they intrude upon my coding, or 2) when I'm not coding (or thinking about code).

Problem 1 is why I personally dislike open offices, and 2 is usually a consequence of meetings or boredom with the current problem. I'd rather be working on something interesting than be comforted by my surroundings because of boredom...

I'd love to be able to code at the beach, or just outside in a nice park... But due to the glare on the screen I've found it almost impossible. Is there a solution?

These problems could be made analogous to problems in other professions as well.

I worked as a graphic designer for 10 years, and a handful of shitty (boring) office temps jobs before that. I'm currently dealing with 6 out of 10 of these problems, and I still love the work. I thank the stars every day that I get to write code for a living.

Glaring omissions:

11. Security vulnerabilities and attacks (and the fear of them) 12. Technical debt

Most of those seem related to working at a crappy job, and would negatively effect everyone, not just software developers.

As a consultant / freelance developer a lot of those reasons are non-existent.

I am in a consulting role and I often make upgrades to existing systems or integrate with existing systems. Sometimes, that means working on a 20 year old system and all the cruft that comes along with it.

I can feel the pain of some of those points. It can be frustrating when you strongly believe that replacing or fixing a part of a system would be beneficial, yet it is not done for political reasons. Personally, I can take comfort in the fact that I've brought the issue to their attention.

As consultant for Fortune 500, I have experienced all those reasons.

Pay, freedom to remote work and days off whenever I feel like is what makes me mostly happy.

I guess it does depend on how you find work. I'm not part of an agency or corporation.

The only things from that list that I routinely have to deal with are #3 and #7. This is usually when taking over old code bases.

But...sometimes I don't really mind that. Refactoring is relaxing to me, but it depends on what mood I'm in.

I also rarely see #1 as an issue. Yeah sure, it really sucks when you spend hours being stuck on 1 problem, but I would rather deal with that than being bored out of my skull.

Doesn't this apply to most any job? People are by nature grumblers, and they grumble about work. Why should software development be special?

Reply on news.ycombinator.com