On the Unhappiness of Software Developers(arxiv.org)
arxiv.org
On the Unhappiness of Software Developers
https://arxiv.org/abs/1703.04993
142 コメント
How do interview when this is your mindset?
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.
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.
Oh you learn that "you just don't say things like that". Interviewing is a lot like sales, where you are the product. So it stands to reason that the "truth" is a movable entity. You build the truth your "client" is looking for, you enhance what would be pluses for them, and keep your real reasons for yourself. After all, they are your reasons and no one else's.
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.
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.
> 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".
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.
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.
Yes, absolutely do what your boss expects. But one can be a miracle worker just for so long. In reality you are moving your baseline upwards, and the day you stop being a miracle worker you become a slacker.
The primary quality an interview tests for is your ability to lie to meet social expectations you do not personally believe in in such a way that it isn't apparent you are doing such.
Preach! As a close second..implementing and/or traversing some kind of tree structure.
If a test looks for the presence of something which isn't apparent, how does any subject pass?
I don't think interviewers are specifically looking for fake in preference to genuine, but they perhaps tend to be satisfied with appearance as an estimator of substance.
I don't think interviewers are specifically looking for fake in preference to genuine, but they perhaps tend to be satisfied with appearance as an estimator of substance.
Learn to be a convincing liar. Once you're "in", go back to your mindset.
Exactly.
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.
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 agree with this fully. I was taught this lesson very specifically after being laid off and doing a stint as an hourly consultant.
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'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.
>It is someone else's business, and I am there to do what they ask me. Which may or may not match to what they need, but that's not for me to decide.
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 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 look it this way: if I were good/smart/eager enough to decide if something is stupid or a waste of time, I may think about becoming the entrepreneur myself. I am not that person. I am a tool. Someone is paying me to develop something that it is important at least to them. I am a professional, I get things done for other people.
"I am a professional, I get things done for other people."
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 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. I keep myself current. I actually assume the project will fail and prepare for it. If it succeed that's great news.
I never had and probably never will have golden parachutes. My insurance is what I know and why I do. It must be valuable for the marketplace, not just for the company I am currently working for. That is my duty.
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 actually assume the project will fail and prepare for it
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 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?".
At some point regardless of feelings you just shouldn't be 100% committed to some else's project, of which you have very limited control (if at all). You can be 90% committed and a professional and still get a lot done and do great work.
In the company's eyes you should be 100% or even more committed. Perception is everything in this case. But you must do it by creating your own reserve space, where you are really 90% (or less) committed while using the remainder to worry about your next gig, because it will come. That's when you learn to apply proactive procrastination (sometimes it pays off to hold off on something you suspect will be cancelled), and absolutely use all the time estimated and allocated. Say whatever they want, managers and people in general take estimates for what it must be. Therefore you make it so.
"I am a professional, I get things done for other people."
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.
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.
This is software development. We are not professionals, and I sometimes say there is no such thing as "software engineer". I am an engineer by education (EE) and I can tell you software development is a long way from being a regulatable profession. Heck if you want to install an outlet or a faucet in your home you need to be properly licensed and insured. But when it comes to developing software that arguably is having more and more importance on people's lives there is no such thing.
>Heck if you want to install an outlet or a faucet in your home you need to be properly licensed and insured.
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.
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.
I've spent plenty of time in my career building stupid things. While I'd prefer to build non-stupid things, as long as I'm getting paid well for it, I will happily build your stupid thing. If you get hung up on needing more control over what you're building, you actually have a few other options:
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.
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.
I've had a lot of existential issues with this. What makes me feel better is that the system in the moment is what matters. Everything gets destroyed in the end as per every world view (goes to a heat death, gets destroyed by Yahweh and a new Earth comes about, wolf eats everything). Nothing you build will last more than one or two generations, statistically. Just enjoy making the thing and the process of trying to solve a problem. Maybe pick which problems you work on.
choose better people to work for. you are not a helpless victim.
Not a helpful comment. Some people have more leverage than others.
It is also really hard to tell before hand. Companies change over time and can be very good at hiding their red flags.
It's easy to ignore red flags. We're rationalization engines.
Yeah, this is what I call the "Marine Model." You and I work like grunts; kick doors in; blow shit up.
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.
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.
Great inisght. I've recently been wondering how I can rebase my values to achieve the same behaviour. You seem like you had a different mindset before -- how were you able to rewire yourself?
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?
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 do my best to have someone tell me to fix them. Not because I lack initiative, but because I saw too many times well- intentioned developers get in a lot of trouble by "taking the initiative" to make things better, to fix things. To the point where one place I worked the word "refactor" was spoken with a high degree of suspicion.
Part of the problem is that well-intentioned developers don't always get it right. The assumption in these discussions seems to be that every time developer starts refactoring, the system is bound to end up better then before. The reality is, that the refactoring attempt may end up as bad or even worst then before - it may end up over-engineered, under-engineered or simply buggy, slower or loosing features people actually liked. Unfinished refactoring basically forces everyone to deal with two different architectures at once which causes quite a lot of problems.
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.
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.
> I come in at 8am, leave at 4pm.
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.
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.
Do you do scrum where you work?
"They" like to say yes, that we scrum. Practically I have a manager that calls biweekly meetings and hands out work to be done in one or two weeks. Which usually is more than enough, but I manage to get everything done "on time".
Every two weeks sounds great. At my last company "they" decided to do scrum. We had stand-ups daily (with 2 developers) and it was horrible micromanagement. They send out our burndown chart every day and if we were behind, the "scrum master" would constantly ask why and if we would make it on time. We had to do estimates and story refinement for hours. It was a huge mess. I quit and will never work for a company that is like that again.
I think "scrum" refers to daily standups. I may be wrong though.
Scrum is a process with way more than just daily stand ups. Obviously a company can do whatever works for them, but formal 'scrum' involves time-delineated sprints, planning meetings, demos, retrospectives, the daily stand ups, pointing stories and a handful of other aspects.
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.
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.
It probably is. I might never know. People use the words "agile" and "scrum" very liberally at least around here.
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
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) .
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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.
I love #1, I just find that it never comes without #2. Problem solving is great, problem solving on deadline is much less relaxing.
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.
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.
It's why people complain about the issues that technical debt brings about.
> "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.
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.
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 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.
I think you need to be able to enjoy problem solving though even if sometimes mid-process you feel awful.
>"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 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 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.
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.
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.
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.
> 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.
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.
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.
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.
That's my favorite part.
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.
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.
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?
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?
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 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.
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.
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...
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.
Although I'd be curious to hear of any recent books that hit the level of these two.
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
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
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
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
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.
If you're a founder, I'd suggest Peopleware and have your engineering and product leaders read The Mythical Man Month
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 think the hard part is the search for the product that solves problems. Not technical debt.
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).
You might like this reading list I put together towards creating and sustaining High Performance Organizations:
https://github.com/pdfernhout/High-Performance-Organizations...
https://github.com/pdfernhout/High-Performance-Organizations...
The Clean Coder is a good guide for individual engineers, but I don't know one for managers.
Check out the book Lean Thinking.
I'd add very long hours sat (or even stood) at a desk. Coding on the beach is less depressing.
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?
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.
> 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.
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.
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.
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.
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.
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 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.
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...
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...
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.
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
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.
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.
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.
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.
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?
At the risk of confirmation bias, this seems to back fairly common beliefs in developer communities... namely that developers are individually optimistic and problems are largely the fault of mismanagement or other externalities.
> 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.
> 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.
Isn't the field heavily skewed towards males as well?
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.
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.
Anecdotally it seems to vary massively between different workplaces. Smaller internet and games companies seem to have a much bigger male skew than larger, "boring enterprise" companies.
Larger companies have more time, energy, and money to worry about their hiring demographics. Everyone else just wants smart people in chairs in front of keyboards.
IIRC the female developer stats were in the double-digits, varying somewhere like 20-40%. A 6% rate is therefore unrepresentative.
Where are those numbers from? Those numbers would imply 20-40% at computer science in universities as well. AFAIK that isn't the case in Europe or the US.
Depends where in Europe.
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.
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.
Care to back this up with links and data?
Think about how many female software developers (not managers) you've seen per guy within IT.
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.
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.
> problems are largely the fault of mismanagement or other externalities
Those externalities are often (not always) manageable through. And a lot of them are caused by developers themselves or by developers having wrong job.
Those externalities are often (not always) manageable through. And a lot of them are caused by developers themselves or by developers having wrong job.
A couple things to combat some of these:
- 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".
- 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".
Interesting. And there was I thinking "problem solving" was what made this gig interesting!
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.
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.
That gets my goat is a problem that gets in a way of solving problem I was tasked to solve.
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.
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.
Is the issue here really about problem solving, or about having to account for your time in excessively fine-grained increments? Given a coarser-grained model of dividing up tasks, wouldn't it be easier to solve the segfault and move on?
In general it's about pressue to get the main task done quickly. I thought of some common reasons I feel this pressure:
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.
- 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.
> That gets my goat is a problem that gets in a way of solving problem I was tasked to solve.
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.
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.
Problem solving is great. Getting stuck on a problem you cannot solve and not seeing any possible way to move forward is what the paper seems to be references.
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.
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.
What was the bug and eventual solution?
It depends. Am I solving the problem of how to implement this feature in an effective and efficient manner? Or am I solving the problem of GOD DAMMIT WHY THE %^&# WON'T ANDROID STUDIO COMPILE NOW?!?!?
The real question is why does the top 3 problems on the list appear?
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 :(
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 :(
The problem is that it only takes one period of bad management to put a company on the back foot from which it takes a monumental effort to recover.
> You won`t be stuck (often) in problem solving if you have good management
How so? Management wont solve tough problems for developers, it is literally developers job to do so.
How so? Management wont solve tough problems for developers, it is literally developers job to do so.
Because good management understands the value in avoiding getting stuck in problem-solving mode.
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.
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.
I understood their point to be that good managers allow _adequate time_ to solve problems in a way that decreases unnecessary stress and technical debt.
Mindfulness is something that should be practiced.
It's perspective that helps me. After all nothing really matters that much at all....
We are all just passing through.
Maybe I got a little too Zen there... But hey keep busy being happy, move away from negative influences
I found the abstract extremely dystopian. Happiness reduced to a function of productivity and a checklist item for cost-efficient management processes. Oh boy... this made me unhappy.
I am surprised management issues are not making the list as a separate category (unless they are under (9)?) because things like your managers never having read the mythical man month, treating team members like replaceable cogs, or politics in general in my experience can be huge unhappiness generators...
My #1 source of unhappiness as a programmer is that most of the software industry is still built on a lock-in business model.
What do you mean by lock-in business model?
Lock-in business model: make the costs for clients to choose a different company for the same service very high. Lock-in is achieved by taking the customer data hostage through cloud storage, proprietary file formats, drm, or other methods.
Another word for this is 'ransomware'.
Another word for this is 'ransomware'.
If the goal is to increase productivity by reducing unhappiness, then I think the so called 'causes' would be more correctly described as 'situations'. For example 'Bad code quality and coding', which is explained as a situation where a developer essentially has to clean up another's poor code, is described as a cause of unhappiness. But I like cleaning up other's shit code. The activity helps me feel good about myself in lots of ways. So I believe the way people handle these situations is the 'cause' of unhappiness. However people who do become unhappy in these situations tend to interpret them as causes, because they don't yet understand what the actual cause/solution to their process problem truly is.
"For example 'Bad code quality and coding', which is explained as a situation where a developer essentially has to clean up another's poor code, is described as a cause of unhappiness. But I like cleaning up other's shit code. "
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.
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.
Cleaning up code requires a lot of testing (which you cannot always automate, e.g. in case of a UI, except if you are willing to invest a lot of time). Not everybody likes testing.
That is a big win for freelancers vs staff developers. Because most of these (time pressure, bad quality, bad colleagues, poor decision making etc.) strongly correlates with better paid projects, and freelancers like money and work for it. So we are very rarely unhappy :)
Depends, some companies helps others replace freelancers with offshore devs.
We are people who talk like anarchists, but work for the worst kind of despots. We are a people who claims to love creation and chaos, but relish in strict order and preditable systems (noticed the missing c- really riled you up, did it?).
We claim that everything is open to discussion, but we have a thounsand little forbidden talk-pieces, and hate introspection.
We claim to be meritocratic, but when it comes to performance, we are stuck in a golden-age "best practice, no experimentation" approach- and claim that to the best there is cause heurecaheuristics.
If there was a guildhouse, it would be build wall-to-wall next to the psychward.
If there was a guildhouse, it would be build wall-to-wall next to the psychward.
> We are people who talk like anarchists, but work for the worst kind of despots.
“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.
“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.
anarcho-capitalist
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.