When things go wrong, you either move on or start fixing things, and that perpetuates your job (hopefully). If things take more time, it is their time. I come in at 8am, leave at 4pm. I don't take my laptop home. I don't work from home. I see their inefficiencies as opportunities for me to spend time on things like learning and experimenting.

But that's me. I get paid enough, I don't need or want to go up the "career ladder". Others may have loftier goals.

I ask this sincerely because this is the mindset that I've noticed has made me the happiest and I'm currently looking for a new place that will pay me more. I've been happier when earning more and working less. I don't really care about what I do while at work or whether I'm using a hot technology or what the company does. This doesn't mean I care about what I'm doing. I do care and put effort in during the work day and I've always had high praise from managers.

Unfortunately, in order to distinguish themselves, pretty much every company wants to market themselves as such a great place to work and of course they ask the question "Why do you want to work here?" when for me the honest answer would be "I would want to work there if you pay the most and I can stick to a max office time of 8 hours per day." But I play along and say generic things about the product and people and show interest.

I find meaning in my life outside of work and more money helps me achieve my outside goals which makes me happy.

As you mention, I do care and put effort. I don't have things coming back to haunt me. I have quite a bit of experience. And I do things fast if I need to. I just don't do them fast just for the sake of it, so I try to be seen as "meeting the targets" as well as "meeting expectations". Because if you are exceeding expectations you are really being underpaid. Well that's my view and my opinion after quite a bit of decades.

Also meet targets your boss cares about. Don't be a miracle worker, you have to manage expectations. In large organizations I can always point to other teams shortcomings, or organizational inefficiencies as reasons for slow progress and delays.

A job is just a job, and a business is just a business. Mistaking either for anything more will lead to a paradox.

Businesses just need extremely specific work to get done. Jobs are ways to get people to do that work in exchange for money.

If you're flipping burgers at McDonald's, you don't reinvent their burger. If you're assembling iPhones at Foxconn, you never add your personal touch. You do what is expected of you, and if you'd rather be doing something else, you need to find a job that matches. And that's it.

And most importantly, if you got paid, you're being appreciated. If you need someone to pat you on the back, know that the business is paying someone to pat you on the back because you are deemed to work better that way, and it's called overhead. It's why you're being paid less than someone who doesn't need pats on the back (probably the guy patting you on the back). Same with dangling carrots.

Unfortunately, there is so much more to being human. So it truly is up to each individual person to fill in their voids. A true professional is defined by someone who is capable of remaining satisfied while accomplishing demanding work.

I've found being senior enough to actually be (slightly) respected is nice in that you can spend time cleaning if you know how to sell it (I just reduced X, which translates to $$$), making your day-to-day easier.

I know that this is the right idea, but it is so painful to build something you know is stupid and waste of time. Its impposible to go home happy knowing what you are building is crap.

I agree, but only if people want to pay "professionally" for it. Additionally, there can be problems with this if you're working someplace where your job is potentially at risk if the project fails.

It's very hard to take strategic direction from folks who have golden parachutes in their contracts. Succeed or fail, they'll be OK, but when you can see the project is DOA, you now have to spend some time preparing to look for the next job/engagement/etc.

I realize not all situations are like this, but have seen enough to understand it happens. You can be professional, but also have to understand that sometimes your best interests and the project's best interests may not line up, and plan accordingly.

    I learned the hard way to always be prepared to 
    move on.

It is quite often out of your control (e.g. the company is in trouble and they layoff your entire department or cancel the project you're working on) and even in socialist Europe there isn't really such A thing as job security (outside of the public sector anyway).

Even huge succesful companies like amazon/microsoft/google/etc sometimes have layoffs. Or they become less succesful for whatever reason you couldn't predict ahead of time and then have layoffs. Or they merge/buy another company and get rid of redundant/duplicate positions.

I do as well, but it is always a bit of a conflict in the back of my mind wrt feeling 100% dedicated to someone else's project. I want to feel that I'm committed 100%, but always have to be preparing for "this will not work out, what is plan B?".

I get what you're saying here (I think). Part of being a professional is putting your own ego aside and not making it all about yourself.

However, a true professional doesn't actually obey an employer the way a simple employee does. And in that regard, regrettably, we software developers really aren't professionals. We can take a personal stand, but there is no professional code of ethics that we serve that stands above the client or employer, at least not in the sense that it does for physicians or lawyers.

It isn't really our "fault", though we could organize better. Professionals belong to associations that have formal standing with government. In many cases, they can't "report to" a person who is not a member of their profession. They must serve their clients, but they are empowered, by law, to stand up to their clients and refuse to breach the ethics of their profession.

That's what happens when you have strong plumbing and electricians unions. They convince the legislate to legislate a form of welfare for their trade.

Small scale plumbing and electrical are tasks a significant chunk of homeowners are perfectly capable of doing without screwing up. It used to be that the majority of homeowners could accomplish these tasks and that was in the days before the Internet.

1. Take on a hobby in your free time.

2. Work for a different company, where developers have more of a stake and help define the product (there are few but they exist).

3. Moving into a "product management" role where you're defining features and requirements, etc.

4. Put your ass on the line and gamble on starting your own company.

However I feel that my experience has indicated that this only works when the brass are present and making such orders. When you're on your own, even when within the context of a organization or team, this is more easily prone to failure.

You talk about them being loftier goals, but maybe they're just different methods to solve different problems.

Anyway, semper fi.

Also, just curious:

> [..] but that's not for me to decide [..] When things go wrong, you either move on or start fixing things [..]

Start fixing things is your own decision or do you wait until someone asks you?

I think that these kinds of experience are behind the word "refactor" being suspicious at some places.

The other issue is that "I am taking initiative" is sometimes euphemism for "I am going to do things my way and don't care to argue with other team members/departments who I expect to obey me anyway by default" power grab which leads to people rejecting changes even as they are right.

This is important, and this is why I'm still unable to let go and treat work as "I'm a tool. I just do what I'm told."

I, like many people in IT, am effectively "end of the line" for our deliverables.

The consequence of inefficiencies isn't "the business makes less money", it's "work bleeds into your personal time".

If things take more time, it's my time. And that makes these issues my problem as well.

http://www.scrumguides.org/scrum-guide.html

NB: I'm not trying to advocate for it - it works for some teams, but everyone is different.

   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

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) .

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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 think you need to be able to enjoy problem solving though even if sometimes mid-process you feel awful.

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.

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.

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.

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

That's my favorite part.

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.

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?

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.

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.

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...

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

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

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

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

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

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.

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.

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.

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 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.

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

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

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.

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

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.

> software developers are a slightly happy population

> the vast majority of the causes of unhappiness are of external type. Since external causes may be easier to influence than internal causes, and since influencing them will impact several developers rather than only one at a time, this suggests that there are plenty of opportunities to improve conditions for developers in practice.

Also noteworthy: this study skewed highly male (94% v 5%). This may be a source of uncertainty.

It wouldn't surprise me if 94% of software developers being male was perfectly true. Think about how many female software developers (not managers) you've seen per guy within IT.

At least for me, it's seldom that I meet female developers. At the workplaces I've been, it's approximately those numbers, perhaps even less.

In Portugal and Spain, many universities are full of females on CS degrees. Already in the 90's my faculty had around 10%.

FOSDEM also has a good presence of females per room.

Meanwhile in Germany they seem not to like CS.

Why would I compare the number of women in one department to the number of men in another? Such a number doesn't mean anything.

Those externalities are often (not always) manageable through. And a lot of them are caused by developers themselves or by developers having wrong job.

- When interviewing for a new role, interview the people you will work with and ask questions about the company. Interview them. Discovering during interviews that an employer or co-workers aren't a good match for you is the best place to figure that out.

- Realize and accept that most software doesn't need to be perfect. There is an acceptable level of quality and then after that it doesn't matter to the business. Sure its likely someone else's money but that contributes to unhappiness. When production bugs happen, tackle them like a professional and save the "I told you so's".

- Same can be said for large waterfall driven software processes. They tend (not all but many in my experience) to have a lot of feature bloat of things people want but never actually use. This could be borne out of politics or appeasing people, misrepresented requirements or the business changes faster than software delivery. Recognize if you work in a shop that does this and come to terms with it or suggest gathering metrics on usage of your system as part of your requirements process.

- A lot of the reasons stem from existing software and issues it has. You might think to steer clear of old code and work at a startup or greenfield project where everything is new. There is a certain satisfaction, maybe enlightenment is a closer word, when you figure out unexplained/broken software and fix it. Have you felt that? You'd be amazed what little fixes to do quality of life for the people using the software. "I am one with the code and the code is one with me".

I guess this puts the emphasis on talking about problems over hiding in a corner and working through them into some perspective. But personally, I find programming under circumstances where I don't get to "spin my wheels" from time to time pretty frustrating.

An example would be the test suite segfaulting on my machine while I'm responsible for hunting down a nasty bug. Often I'll take a stab at the distracting problem, e.g. reinstall Ruby and gems with native extensions. If that doesn't help

I'm faced with following choices (and due to time zone difference I need to decide before my manager gets online):

- give up investigating and suffer the segfaults (time already spend is a sunk-cost with nothing to show) - disappear into segfault rabbit hole, all the time stressing that I should be doing something else

In isolation I'd be happy to focus on solving either problem.

  - external, e.g. bug hurting our clients.
  - feeling bound by an overly optimistic estimate, like couple hours vs. a week
  - can't focus, procrastinate and then rush to get the work done
  - imposter syndrome and constant feeling that I should have done my assigned task long time ago
  - personal issues forcing me to take some time off and delaying shipment
  - having already spent considerable time in some other rabbit-hole, especially without asking for permission 
  - misunderstood something, wasted lots of time implementing wrong thing but don't want to admit
  - scope creep, a feature that's too big and too long in not-yet-ready-for-deployment, risk of interruptions, merge conflicts and being too big to test properly grows

Without this kind of pressure I often find solving problems like debugging library code or git forensics quite fun.

I'm fine with fine-grained time accounting. Part of a decade of remote freelancing. Nowadays I do it habitually without being required.

Amen. It's so frustrating to stretching the time involved in solving what should be an easy problem by 10x because of poor or inconsistent API documentation.

It's one reason I hate 3rd party libraries and the abstractions they cover - they always fall apart, and I have to spend an inordinate amount of time understanding why.

I worked on project once where we had a single show stopping bug preventing us from getting our new release out. At first it was a really fun challenge, but as days turned to weeks and we where no closer to finding out what the hell was going on it got more and more dispiriting. If nothing else it makes you feel dumb as fuck and you start questioning whether or not you actually are a fraud after all.

1. Being stuck in problem solving 2. Time pressure 3. Bad code quality and coding practice

You won`t be stuck (often) in problem solving if you have good management and "no question is dumb" atmosphere in the team. You won`t have (often) time pressure if the project is managed correctly. You won`t have bad code quality if the management choose to pay for several very good devs/architects and did not impose constant time pressure. Etc, etc.

My number one reason to losing motivation on work (and subsequently quitting if that does not improve) is a lack of good leadership. I can sustain anything else (if it is not constant) if managers are true leaders. Sadly, they are in a very small minority from my experience so far :(

How so? Management wont solve tough problems for developers, it is literally developers job to do so.

It's not that management solves the problems. It's that you structure processes such that they arise far less often, and can be resolved far more readily.

Another word for this is 'ransomware'.

I like doing it too (sometimes), but I find that:

* It's very low visibility work by its nature. People outside of the team will see bugfixes and new features but they don't see prevented disastrous bugs and don't necessarily see speeded up delivery.

* Dysfunctional working environments tend to go hand in hand with bad code.

If there was a guildhouse, it would be build wall-to-wall next to the psychward.

“Talk like devotees of laissez-faire capitalism, work for capitalists, and aspire to be capitalists” is perhaps just as accurate and makes more clear the line unifying the different bits.