A lot of office/corporate routines and rote weight is taken off the shoulders with remote work. For young people, it might be a challenge to engage in social activities, but if they take the initiative, for e.g. travel around and work, they can find plenty of social events, activities to meet and engage with people or just enjoy themselves.
There is that, but, and I am saying this as an ardent remote supporter, in person appears to have an edge over remote in terms of training ( there are definitely things I would not put in official training materials or even in recorded zoom/teams/we call ). I recently joined a new team and even with previous experience of how things actually work, it was an adjustment how this new ( to me ) corporate structure really operates. It is the little things that can surprise a complete newbie. In person advice can be invaluable.
Discovery of other teams is also somewhere in-person has the edge. Once you've had the contact and made the connection it's less critical, but you can't (yet) beat physical serendipity for getting to know useful other parts of the organisation.
I think this comes down to the newbie taking initiative to seek help. In person, it’s easier for others to help a newbie that doesn’t know when to seek help (they can “see” them struggling). As long as the struggling new person seeks help, remote work is superior for the actual help to be administered. Screen sharing, meeting time synchronization, etc. all make it easier to help someone remotely.
To me the main difference is that you can still focus on work while showing up. I wouldn't be able to just bring my laptop to an in-person meeting, zone out and clank away on your keyboard. This largely removes the main issue I had with most meetings - that I have to stop doing useful work.
Remote work aggravated my unhappiness since it means I have very little social interactions.
This last week was the funnest in a long time. A colleague who works at an office 7000 miles away flew in the for the week so everyone on team locally came into the office this week. First time in over 2 years I've seen everyone there. It was really fun.
Remote made me very isolated, and especially in a team where we are 3 people and everyone else is 15 years older than me with kids and I have nothing in common with them. I could go do random meetups outside work but that's usually weekends as I live further away from bigger city, so that means that at least 5 days of the week I stay home barely talking to anyone.
I just tried remote and it's a strange blend. No commute makes the morning a lot lighter. I can operate as I want without having to tag along others (lots of pauses or chit chat usually..) but it also makes me more stressed (I plan to do 20min walks outside to replenish). I don't get along with most my colleagues either but my main one is cool enough.
I think this is just a temporary phase until society figures out how to adjust to the new environment. Nothing about remote work enforces isolation. You can work from a coffee shop, you can work from the beach, you can work from a library, you can work from your friend's house, and yes, you can work from home.
If home isn't fitting for you, try anywhere else on Earth. There are probably new environments that are possible that have not yet been created. Let's explore those. It's very likely that the office isn't the single best place on Earth.
This looks like one of those BS ridiculous-syntax fraud-publications submitted to academic journals with the deliberate intention of showing them (the journal and its editors, and perhaps the whole scientific establishment) to be a pack of creduolous wankers, basically. Kind of obvious here:
> "The happy-productive worker thesis states that happy workers are more productive. Recent research in software engineering supports the thesis, and the ideal of flourishing happiness among software developers is often expressed among industry practitioners..."
'Recent research in software engineering...' now, what does software engineering research have to do with emotional psychology, again?
> what does software engineering research have to do with emotional psychology, again?
Psychology of labor is a thing, and has been for ages. The idea behind it is simple: it's people with a mind that do the labor, so their psychological state has influence on the work done. Is it software engineering? No, but the article purports to identify factors that influence the psychological state during software development.
That said, I do believe such studies to be of minimal value. Voluntary surveys are absolute bottom of the barrel. Identifying 219 factors from such a study seems like analysis gone mad. The extensive discussion of the non-normality of the central happiness statistic seems a point in case: it's trivially visible, it's not interesting, and doesn't play a role in any further analysis or conclusion. They do remark that the mean value they find is higher than in other studies, but can't explain it. Not that they need to, because nothing would change in the paper if the value had been lower.
Basically, this looks like an experiment from a starting PhD, who needs to push out one paper per year. Sadly, it isn't. The authors are senior researchers, who seem to have little idea of psychology.
While I’m sure the scientific establishment is full of “credulous wankers” as opposed to our industry where everyone is tip-top-magoo, wouldn’t you agree there are more factors for you to accept or quit a job other than money? And those factors are mostly between your ears?
Freq Cause
186 Being stuck in problem solving
152 Time pressure
107 Bad code quality and coding practice
71 Under-performing colleague
63 Feel inadequate with work
60 Mundane or repetitive task
57 Unexplained broken code
42 Bad decision making
40 Imposed limitation on development
39 Personal issues
I'm doing the mundane stuff now, for a couple months actually. Stand up repo, pipeline, sem versioning, tests.. haven't actually written code yet/built something. Just copying configs/duplicating stuff.
I personally don't think happiness is very different from motivation. Happiness is the state of being motivated. Unhappiness is the state of having no motivation.
The 3 key ingredients to motivation are: autonomy, mastery, and purpose.
Nearly every time I've been unhappy writing software it has been because of a deprivation of autonomy, mastery, or purpose.
I've been ordered (deprivation of autonomy) to work on things I didn't think mattered (deprivation of purpose) with a language I wasn't familiar with in a context I wasn't familiar with, in a way I thought was wrong (deprivation of mastery and autonomy) for political rather than technical reasons (deprivation of purpose). I have never been unhappier and less motivated than that.
I think there is a stark difference between motivation and happiness.
There exists negative motivation. If you have $50k in credit card debt, you are very motivated to pay off that debt, but you are neither happy to have the debt nor happy to pay. You just plan to be more happy when it's over.
This kind of motivation can also be present on the workplace, along with positive motivation (when you are happy about something and want more of it).
The post you’re replying to is talking about drivers of intrinsic motivation. Paying off a debt and getting paid money for your work are examples of extrinsic motivators. Intrinsic motivation is generally thought to have a larger impact on the quality of output, although the line can be blurry sometimes.
You know, you say that in jest, but having experienced a fair amount of depression in my life, I can definitely say that I have been so unmotivated that sunsets do nothing. "why watch the sunset, I've got all this other stuff I have to do and even if I do it life will still suck and it's so much effort to drive somewhere just to watch something beautiful alone, life is so meaningless." (exaggeration, kinda)
Robert Sapolsky (Stanford Professor) has said:
> If I had to define a major depression in a single sentence, I would describe it as a "genetic/neurochemical disorder requiring a strong environmental trigger whose characteristic manifestation is an inability to appreciate sunsets."
Odd, I've felt the same but always attributed it to being "too motivated" by other stuff. I can't enjoy a sunset because I'd be thinking about something else I'd rather do.
I feel like their is a bit of a heavyhanded personalization in the way these conflicts are presented. They leave it rather ambiguous how much of the dilemna is intrinsic versus how much is extrinsic. The external factors that are listed are closely knit: unperforming co-worker.
I think engineers are hyper competent can do individuals with deep belief in possibility & potential. Few organizations can match & support this vanguard fleet well/at all. A corporate entity can very rarely accept & permit itself to support something far beyond it's grasp. It has to be willing to negotiate & work with people who know more & have more insight than it can. Almost no corporation can find that humility. They cant accept their own limitations/ignorance & trust/enable.
There's some org blame possible in this list. But all masked/hiddenz said in typical corpspeak to protect the guilty non-technical cant-knows.
I think you need a balance. If you're completely stuck most of the time, you're going to start dreading work. But if you never have to make a real effort, you will be bored.
The first part is true from personal experience. If you make no progress on something you'll start to wonder if you're the real problem. That's not fun, and more importantly traps you in a cycle of wanting to get out, but being scared that you'll just fuck up the next thing you work on.
I had a similar initial thought - I find unsolved technical problems genuinely thrilling to work on - but then I noticed the word ‘stuck’. That implies having run out of ideas on how to approach the problem and I can imagine that being stressful. Perhaps you are similar? Or do you also enjoy having run out of ideas?
This has never happened for me the closest I have gotten is that I have to give the client to option of sticking to our initial plan or change it for the expense of more time and money.
I wouldn't really call that being stuck with a problem tho, its more the client is stuck with a decision they don't want to make.
I think this is the core value generation of software engineers. The problems being solved that is. If you like your job, you’ll relate to this feeling less. It also make sense that the hardest part would be highest on the list.
There's problem solving and then there is "working around" things like bad code, bad coworkers, slow hardware, being stuck with old versions of software...
It's a little unfortunate the paper doesn't go deeper into this beyond a few lines:
>As one respondent commented: “I feel negative when I get really stuck on something and cannot get around it”. Another respondent elaborated: “I also thought of situations where I’m debugging some issue with the code and I can’t figure out why it isn’t working – when it seems like everything should work, but it just doesn’t. This is definitely one of the biggest gumption traps I encounter”.
To me, the most annoying part isn't just getting stuck, but getting stuck in conjunction with the (lack of) complexity of the issue in theory, and the time pressure (#2 on the list). A lot of problems just shouldn't take as long as they do, but communicating with frameworks, other people's code, poor assumptions (#3?), weird requirements definitely make problems a lot more difficult.
The majority of the work is just trivial plumbing in theory. It's not some complex algorithm. Yet the complex algorithms are often documented far better, you're given more time, and at least personally, it's a whole lot more interesting to work with than fighting a Frankenstein application just to do something extremely minor like conditionally changing font colors.
Your comment sadly repeats the same old software developer tropes, namely:
* Managers create all the problems,
* Problems not created by managers are created by my team members,
* Everyone around me is incompetent except myself,
* The problems I create have everyone else to blame but myself, because I'm flawless and I was just put in a bad situation.
* goto start.
I've been in a fair share of time-constrained problems, but honestly deadlines tended to slip because of a mix of emergent technical requirements that dev teams didn't managed to see beforehand, and scoping tasks that severely undershoot the requirements. Scoping and planning is hard, specially with limited info, and you can't reasonably allocate 10x the resources to your project just to have a decent slack in the critical path.
Also, bad code can and often is subjective,and I've seen competent and above-grade engineers underperform because of task- and life-specific issues.
It's high time that developers cease the "everyone around me is incompetent and responsible for al problems" mindset.
Meh, you gotta admit management of software projects tend to suck. Yes scoping and planning is hard, but management that don't even try either (and is not agile either) is fairly frequent.
Also, we are for some reason blessed with management with not much soft skills. Stuff like new manager coming in and insulting people right and left on the first day with no reason just because they are insecure or arrogant is frequent too.
There are good manager, I worked with some. But bad management is frequent and there is very little accountability for managers, so they get stuck for years and decades.
GP is crude, but it's not too far off reality. Managers are the first line of defense in ensuring there is slack within the team to pick up what is problematic. By instilling a mindset of "sales/finance/features/bug fixes come first, slack is a luxury", they are directly telling you the health of the codebase long term is not your primary concern, it is getting stuff done on the short term. Instilling that mindset then seeps into everything else.
Make things more open-ended so you can change things later? Too risky, too time-consuming. All frameworks, methods, etc. used become increasingly more closed off, and fixing them after the fact is an afterthought. 2 years later something that should take 2 hours now takes a week, but who cares.
Hiring weaker individuals when your codebase has no obvious flows? Clear signs of executives, HR managers etc. pinching pennies. Don't set people up for failure, and use stronger individuals to create environments where weaker individuals are set up for success instead. This is leadership and teaching 101.
No slack in the team? No time to work through codebase problems. Most of all, assumptions that there will be no slack cause the team to become so skeptical, they won't even mention long term issues. It creates the very mindset they claim to dislike: one where mercenaries shine, getting a quick buck and not caring about the feelings of those coming after them.
The only thing I don't agree with, is not matching individuals. There just isn't enough interesting work for the entire software developer crowd to go into. CRUD-plumbing webdev rules the world, it is extremely unimaginative but it pays well. Ironically, having the entire industry take a breather and look at the problem from a higher level might be the thing to make it more interesting and less painful, but I doubt there will ever be enough jobs in the more complex, visual, animated and/or hacky fields anytime soon to accommodate all the developers now stuck trudging in the stereotypical CRUD webdev shop.
I say this knowing someone from a different, non-management discipline will run into the same issues while working in a software team. UX, UI, graphics artists, testers, etc. all suffer similarly from management incompetence.
> Managers are the first line of defense in ensuring there is slack within the team to pick up what is problematic.
They are, but the first line of defense is often broken due to problems that are controlled, if not outright created, by developers.
I mean, isn't feedback from developers the main source of info available to a manager? What if that info becomes highly unreliable due to natural occurrences like emergent requirements? What happens to a schedule when midway through the project someone realizes there's something fundamentally broken with the architecture put together by the developers and suddenly you need a major rewrite to be able to meet your requirements?
Don't confuse accountability with responsibility. Managers are held accountable, but developers can and often are responsible for misdirections and blockers and the need to rework.
Trying to pretend that the role of a manager is a Dickensian figure whose purpose in life is to rain misery on developers, who are perfect and flawless, is not a honest starting point for a discussion on unhappiness of software developers.
>I mean, isn't feedback from developers the main source of info available to a manager?
Then why is that feedback routinely thwarted or ignored in so many places? You make it seem like developers aren't giving feedback. Most places I worked at, at least 1-2 developers in a team of 7-8 were passionate enough initially to provide feedback. Then their feedback gets shot down repeatedly for no other reason than "low priority". What do you think happens to people who have to make a conscious effort to document such issues, articulate them and provide potential solutions? They figure "you know what, this isn't worth the effort, it won't get picked up". That's valuable time they could spend coping with their frustrations instead of hopelessly tackling them head-on.
Managers are held responsible because when we speak of managers, we're not just talking about middle managers. We're talking about all managers, including the executives. If those executives prioritize short term sales over long term company health, don't be surprised when your ICs follow your example. If you're a leader, set the example you expect others to follow.
>What if
"What ifs" are primarily exceptions. How about we tackle the vast majority of cases where short term financial gains are prioritized over long term company health? That's where the feedback matters most for passionate ICs, and that's where feedback is waved away the most.
>Trying to pretend that the role of a manager is a Dickensian figure whose purpose in life is to rain misery on developers
You're the one claiming this. Don't take us all as not understanding the point of view of executives. Understanding doesn't mean agreement, nor does it mean the chickens won't come home to roost someday. If you consciously decide it is worth making your codebase a complete mess for short term gains, don't cry when in 5 years, all that's left is a bunch of jaded developers only in it for the money wondering why it takes them ten times as long to fix something trivial.
In my 15 year career I’ve never seen line manager being let go for poor performance. I’ve seen a good number of underperforming devs getting canned and some higher-ups (usually for political reasons or just phoning in completely) but never line managers.
> I mean, isn't feedback from developers the main source of info available to a manager?
Of course it is, that's well-known.
But for 20 years of career 99% of all managers I ever worked with outright ignore the feedback.
Most people should not be in positions of power -- ever. It quickly turns into an ego trip where inconvenient facts are ignored and hand-waved away. And always letting somebody else deal with the fallout of your incompetence.
Programmers are not stupid. With your feedback routinely ignored you learn to keep quiet -- why expend energy on something futile? Or you change jobs.
Take a wild guess which of both happens 90% of the time.
I was a first-line manager (a "sergeant," if you want to use a military analogy) for 25 years.
I deliberately stayed at that level, even though I could have easily bubbled up higher.
I felt that I could make a big difference to my team, and, by running a good team, make a big difference to my company.
There were a lot of problems in the corporation; bad decisions, HR issues, administratium poisoning[0], etc., but the consensus seems to have been that my little team was really quite effective, and I kept engineers for decades.
Managers can make a big difference for the positive.
How exactly do you "manage" a creative process to respect a deadline?
Do you tell a painter to get it done by Monday?
That's why small iterations are there in the first place: to constantly add incremental value, not "big bang" plan-the-work and work-the-plan but reacting to change.
I guess that depends on whether they are operating as software engineers or software artists.
Sure, an artist can have leeway for their creative efforts. But allowing artists to work on a muse-driven timeline is also why the stereotype of a "starving artist" exists.
Engineers on the other hand have some product with at least a baseline of utilitarian value. Those generally need timelines because somebody is planning on a delivery of that utility.
But I think both those are besides the point. You can have a structured process that also integrates creativity. I think treating them as mutually exclusive is a false dichotomy.
> I reckon there’s some selection bias here too, people who perceive themselves to be incompetent probably talk about it less.
The issue here is not what's the true skill level of anyone in the team. The problem is this recurrent theme of software developers demeaning everyone around them while portraying themselves as flawless saviours.
A key trait of software development is JIT onboarding and continuous development. If you develop your skills and today you're a better developer than you were yesterday, that means that yesterday you were a worse developer and quite possibly quite bad by your measuring stick from some point in the future.
Thus if JIT onboarding and continuous personal development is a basic aspect of software development jobs, why is not being ab absolute expert on everything the target of so much criticism and abuse?
I often look to the work I've done in the past and often times I come across less optimal choices that today I wouldn't make. I'm sure the only ones who don't experience the same are thise who learn nothing from anything. Therefore, why use that as a target for abuse?
Yet it's all too common today. Here's a fun exercise for anyone: imagine what would happen if 10% of the team would go away in the next month. Now imagine if it was 80%. For how risk-averse companies are, it's pretty crazy how bad their back-up plan is should the latter happen.
I think you hit the nail on the head here. I am a lot more understanding at this later stage in my career when someone shows me a big ball off spaghetti in a project. I don't know why decisions were made, what trade offs for time or requirements were made in the past, what designs might have made sense that got turned upside down with new features, etc. I tend to shut down sentiments like "This all needs rewriting" or "What on earth was this person thinking" as much as I can.
Most of us are decent enough at our jobs, and generally the industry does a good job of weeding out those who can't perform or they end up lost and irrelevant in some big company. There are certainly some bad developers out there, but there's bad doctors, bad lawyers, etc. in the real world too.
That said, the impact a bad manager can have is definitely of a greater magnitude than a bad engineer, generally speaking.
Hard agree. It annoys me that this has the air of a “hot take,” but I don’t believe anyone wakes up in the morning and thinks, “I’m going to write overly clever spaghetti code today and do as bad a job I can.”
People are generally good and want to do a good job and be recognized by their peers.
Different people have different strengths and skills. It’s the sum of those things that makes a team. Alone we could do some of the things we want to achieve but it’s together that we can make it happen.
What I’ve noticed over the decades is that performance on large teams is largely a function of systemic behaviors and culture. The larger the “team” (ie. everyone you have to interact with to get something built), the less any one individual’s performance matters.
In particular I’ve seen situations where every single person is working hard doing their job in a defensible way, but the code base is heading towards a cliff because no one has the incentive and/or skill set to point out that the short term decisions made on either side of the engineering /product divide are steadily inching us towards a state where the code base will be too complex to add a feature or fix a bug without creating more bugs.
Ultimately this type of problem has to be owned by management with support all the way up the chain in order to be solved. That doesn’t mean ICs and PMs don’t have a role in the solution, but this is why engineering management is hard and requires technical depth.
> I don’t believe anyone wakes up in the morning and thinks, “I’m going to write overly clever spaghetti code today and do as bad a job I can.”
Tearing down a straw man is not an impressive feat.
The inconvenient truth is that a lot of programmers are just not that good. They lack the self-awareness, insight and experience to look into the near future and realize they're contributing to the problem.
I was there too. Facepalmed really hard after I realized it years down the line.
> Tearing down a straw man is not an impressive feat.
Neither is being cynical.
Everyone is at a different point in their life and has different skills and has the potential to do good work.
I don't know what problem you're referring to. Maybe you could enlighten us and tell us what it is about self awareness, insight, and experience and gazing into crystal balls that make developers, "good."
You said that people don't write spaghetti on purpose. And I said that lacking in certain qualities makes people write spaghetti code unwillingly and without realizing it.
If you don’t realize you’re writing spaghetti code how could you do it on purpose? Most people don’t write spaghetti code on purpose. They’re trying to solve a problem with the skills and knowledge they have in the only way they can.
You seem to attribute spaghetti code to a personal failure to have characteristics you think are essential. How’s anyone supposed to live up to that?
I have a different theory. I think that it’s a combination of things which cause spaghetti code. I agree with others here that poor management is a strong factor. Also poor communication, time pressures, vague specifications, insufficient proof or testing, a lack of documentation, family emergencies, lack of motivation, general anxiety, social dysfunctions on the team, and so on.
Everyone I’ve worked with usually had something going on for them. Even if they were just starting out or changing careers or had been at it a while but felt like they weren’t getting anywhere.
The bad developers, to me, were the ones who brought others down when they could have raised them up.
Sure, spaghetti code can and is also happening as an emergent property of a system that's increasingly succumbing to entropy -- due to all the factors you enumerated. That too. And I am saying that a lot of programmers lack the skills to recognize they are in a situation that promotes spaghetti code and they don't resist the symptoms that lead to it.
Can we live up to that? Absolutely, but it takes time, practice and a lot of screwing it up -- so, sadly, it can't happen with people who are still kind of fresh. Sad fact but what can you do. I made my peace with it, begrudgingly.
Sometimes it's a deliberate decision. Startups, for example, are generally not in the business of writing robust, maintainable, performant software. They're usually searching for a market niche to exploit and happen to use software to achieve their goals. They prefer moving fast, iterating on designs, and pivoting off in different directions.
To spend the time and effort to write robust, maintainable software would slow them down and give away their niche to a competitor. So it makes sense to hire decent people and toss code at the wall until they find that niche.
Other businesses in industries like security or real-time systems prioritize and value different things. There's usually more of a focus on performance and reliability. That means longer development timelines but the cost of failures is much higher.
> Scoping and planning is hard, specially with limited info, and you can't reasonably allocate 10x the resources to your project just to have a decent slack in the critical path.
Why not? If you don't have an accurate understanding of the problem you NEED to allocate extra time to gain that understanding or redevelop as the requirements emerge.
> emergent technical requirements that dev teams didn't managed to see beforehand
What? So developers that see poor breifs and ask for more time to manage that lack of information can't be given that time but then its the developers problem for not asking for more time to manage that?
Your developers don't have a crystal ball!
It's high time that Management stop blaming developers for the things managers control.
I sort of simultaneously agree and disagree with you here.
Are managers at fault for all problems? Intuitively I would very much doubt that’s true of any project anywhere.
Are managers responsible for all problems? It depends on the environment and level of autonomy but.. kinda, yeah. The first rule of leadership is that everything is your fault.
You kind of have to pick which one you want to define “to blame” as here, but I’m tempted to stick with the latter, if only because I don’t know of a lot of managers that had guns put to their head to take the job, and my own experience tells me that the pay disparity usually covers it.
If you are in a personal relationship that works, you will know that any successful team boils down to the interaction between the members of that relationship.
To blame one party, is immature IMO, even if objectively there might be some truth to it.
In any team situation there will be humans involved who have shortcomings - even the top all-rounders have them.
The ways that other team members can react to those shortcomings are multifold. There are ways of reacting that bring out the strength of the other members and hence create a stronger team overall.
It requires a common understanding of- and focus on- the common goal. If a team member furthers his own goals only, they are the problem and not the possibly imperfect manager, for example.
This resonates with me. Every bit of unhappiness I've felt in my career so far has been caused by one or more bad managers. The main issue for me has been the final point about "Imposed artificial limitations" - I cannot count the number of times that I've been forced to use an inefficient tool or do something in a sub-optimal or downright incorrect way (knowing that it would have to be re-written later) by a bad manager... In some companies, it was a daily occurrence; that's why I never stayed at a single company for longer than 2 years. It's almost impossible to find a company that lets me implement things correctly.
Thankfully, nobody could constrain me in my open source work. I (with the help of community members) built:
- Capitalisk (https://capitalisk.com/): A lightweight quantum-resistant blockchain which is less than 5K lines of code.
- LDEX (https://ldex.trading/): A deterministic decentralized exchange (DEX) which can work with many different blockchain protocols. It's less than 4K lines of code in total and only has 3 small third-party dependencies (including sub-dependencies).
> under-performing colleague - why not fired already ? Management
Everybody underperforms once in a while. With enough coworkers, there are always a few on that bracket, even if no one is incompetent.
> Feel inadequate with work - picking wrong ppl to do the job
You are the one that controls how you feel and what jobs you accept. Are you complaining that management hired somebody for doing a job that they need done?
But indirectly, a lot of times management causes those issues by adequately responding to market needs. The world sucks, and while managers do create a lot of problems by themselves, they didn't create them all.
I keep thinking about solutions to these, as most of them feel artificial. Very often it's the social dimension of them which are harmful.
If something is important and I don't feel hugely guilty if I fail, I will enjoy time pressure.
Repetitive tasks can be amazing, analyzing the patterns and optimizing them away is a cool exercise. It hurts when people forbid you to do so ("don't write a script for this" "why are you changing this to do it your way, it's not right"). Same for imposed limitations.
Underperforming colleague is only an issue is if it's unspoken, not discussed or imposing secrets on you. If my colleague is slow then I want to reallocate the efforts so I can do a bit more to avoid him dragging down the team, and I just don't want the manager to bother me with slow perf if there's a slow guy nor I want that slow guy to force me to lie so he can stay his way. It just has to be open and optimized.
Unexplained broken code requires a shift in thinking: freedom to break it, freedom to get time to do so. You need to reverse the context, system and desired outcomes to improve understanding and fix it.
Another aspect is that I think adult life removed a lot of important emotional layers: no more open challenges that tame into natural competitiveness, that unleash positive pressure and brain activity leading to learning with more fun. A lot of jobs devolve into politics. Quite often I've heard people tell me "shh don't tell we're done so we can slack a bit". From the smallest jobs to highly paid engineer.. same behavior occurs. Kinda creates low levelling.
Your last is extremely easy to explain: if you say you're idle your immediately given a new task.
That's not a bad thing per se. However, management always fails to account for e.g. mental fatigue after finishing an important milestone that most of the time has been grinding hard at for the last month.
That fatigue needs a week or so to disappear by itself -- just getting one good massage, sex and sleep doesn't fix everything. If you're loaded with work again starting tomorrow you'll do a sloppy job and will keep accumulating more fatigue.
I'm not saying an army of unmotivated lazy slackers doesn't exist out there. It absolutely does. But not everyone is like them. Sometimes people really do need to relax a bit in order to recover their ability to be useful to the business.
Our stupid system of requiring 8h a day for 5 out of 7 days misses 99% of all human specifics and it simply doesn't care. That's not okay.
I would also add that we are never truly done. Always refactoring some parts, changing some underlying library, ... . Given how things are we deprived of the joy that, for instance, a civil engineer gets when a construction project is finished.
Sure, but most of the things get completed at some point. In my personal experience when something gets close to that stage in SWEland it's time for a rewrite or something else along those lines
Bridges also don’t have product managers who are judged solely on what new features they can add, and a business model and relatively fast iteration time that makes that possible.
Interesting the number one annoyance is basically one of the reason I love Software Dev work. The high after finding a good solution to a problem is the best.
Is this a real thing? I have never known there to be a technical problem in work that I wasn't able to solve, all of my problems have been from ever changing requirements and clients refusing to give detail.
Is there a role for me that maximises technical complexity and minimises managements role?
Almost had an outburst when I read this. I don’t want to live in a bubble of happiness, I want to work hard, learn a lot and make the team/company wildly successful. To me that’s fun.
I guess I did say that… Would delete it, but can’t so I’ll clarify instead. I just think that “happiness” is sort of a banal goal in life and at work. However, the study’s definition of happiness included meaningful work, and I have to admit my comment was reacting to something that was not said.
Then they'll be discussed in a retrospective, into an endless discussion causing the meeting to drag on, only to be concluded that taking on the issue takes too much time in the face of endless feature requests and bug reports.
Half a year later, it will be discussed again. The odds of the issue being picked up are higher, but still not high enough. The same song and dance is performed, only for the issue to be put all the way down on the backlog, the place where issues go to sleep forever.
Yes, it's also the part of the process that has the most "Arbitrary bullshit" in it. You can't logic your way through it, you have to know the Special Arcane Knowledge in order to configure it all correctly.
I also argue that we're probably fucking it up a lot, causing it to be more painful than it needs to be, but that's because we consistently get our developers to do infrastructure work.
A corollary to this, locally running the code AND integrations is essential. If you don't have the ability to replicate the full system locally, your devs are hamstrung and will take much longer to solve what could be very easy problems if only they could have debugged it locally and quickly. This is related because if your infrastructure is shooting for the moon in complexity, your devs have little hope of replicating it locally.
The perversion of it is that it comes across that I’m against DevOps. I’m absolutely the opposite. I’m against attaching bullshit marketing labels to good practices and making them a cancer on the project (cough devops, agile cough).
I’ve dealt with this recently. The “DevOps guy” was a toxic, condescending gatekeeper who wouldn’t co-operate with the engineers at all, but had the ear of the management.
He had a bunch of servers and builds he was really pleased with that were not at all documented and completely useless to everyone, because no-one understood it and couldn’t ask questions.
Good ops should be utterly transparent and utterly out of the way. Not hidden magic, just so easy to understand that it ticks over doing what it does without interrupting your workflow. And always reproducible locally.
Give a prick even the slightest chance to poison your company and they will is about the only 100% reliable piece of advice I could give anyone in this industry.
> I’m against attaching bullshit marketing labels to good practices and making them a cancer on the project (cough devops, agile cough).
There is absolutely no bullshit in replacing waterfall's big upfront design and risk-prone one-shot dev project with an iterative process where at each cycle you reevaluate your course and your planning, always based on developer feedback.
There is also absolutely no bullshit in avoiding the mistake of artificially separating the devprocess into sysadmin stuff and dev stuff, and actually get developers directly involved and more importantly become mindful of the reality of everyday operations.
Portraying agile and DevOps as bullshit is clear telltale sign you are completely oblivious to the issues software developers face on a daily basis, and how agile and DevOps help solve or mitigate them.
3) I never did that. I’m fully aware of the issues software developers face on a daily basis. I am one. Same as almost everyone here. Agile and DevOps (capital A, capital D, capital O) are corrupted buzzwords used to saddle engineering teams with snake oil salesmen and deeply suspect printable credentials.
But by all means you keep on throwing around baseless aspersions about who has the right or wrong kind of experience if they say something you don’t like.
I have yet to find a dev job that includes serious engineering and problem solving. At that point if the check is high, I'd write yaml pseudo confs if they want to.
I’m surprised that reward misalignment is not making the list.
Seems to me like in many places, career success is mostly driven by metrics that are not related to good software engineering practices (specifically showmanship). Normally I would expect success to be measured primarily on metrics closer to the actual professional skillset.
Not arguing for or against, just surprised not to see it in the list.
There are very few metrics you can usefully apply on the individual level which don't turn into hideously misaligned incentives when you tie them to career outcomes.
It's different at the team level, but nobody's really cracked it for individuals yet that I'm aware of.
- Junior developers who can't get their code pass code review process
- Senior developers who don't know what's going wrong in a microservice products. Rabbit holes are everywhere where you don't know where, who, how to fix the bug in a strange service.
There was a big switch at one point to people doing the career for money, which is totally understandable. They may have never played with or fixed computers for the fun of it.
That's true, but there are various jobs. Problem solving can be fun, but it can also be trying to fit something that's easy on paper into a badly designed or incomplete system, for the nth time.
To me "stuck in problem solving" doesn't mean what it sounds like. Stuck in problem solving means putting out fires. You're constantly in a losing fight against the decay of the current system and therefore you never get to actually solve any of its problems. You're stuck in the solving phase, and never get to the execution phase where you get to interrogate product market fit and the needs of your users. You're forever "solving" the same problem but the solution is never implemented and in 6 months you'll be asked to solve it again.
They quoted some people who described what they meant:
> “I feel negative when I get really stuck on something and cannot get around it”. Another respondent elaborated: “I also thought of situations where I’m debugging some issue with the code and I can’t figure out why it isn’t working – when it seems like everything should work, but it just doesn’t. This is definitely one of the biggest gumption traps I encounter”.
It depends on what is "problem solving". Philosophically everything is problem solving.
Here's a contrived example.
Let's say you became a house builder because you liked building houses from scratch. In a few years you find yourself working for a company and you are the window frame expert. You calculate, design, draw windows for the bespoke houses. You also make sure they fulfill building regulations. All day long. Note that you don't get to make the windows, other guys in the company do that.
Then you realize that this is not what you had in mind when you wanted to become a house builder. But the company pays you very well and you have some nice co-workers. You need to leave but you don't.
We can argue about the specifics, but stuck in solving that type of problems (especially if it's for incompetent co-workers) can drive you mad in the long run.
The specific type of “stuck in problem solving” is outlined in the paper. I think it’s just the core value generation of the engineer. It’s both the hardest part and the most fulfilling to execute.
1. "stuck solving a problem I should be working on" That's awesome. I call it flow and truly enjoy it.
2. "stuck solving problems pushed onto me" Oh wow, how I hate that. Like when a user f*cks up their account on a Friday evening because they mixed up the "Delete" and "Rename" buttons (how do you do that? they are even color-coded..) and of course they have an urgent deadline so now instead of going home early to enjoy the sunshine I have to clean up this mess. And of course it's always the big important clients who employ cheap unskilled employees, so of course their mess gets triaged as critically important.
I believe the study intended to poll for #2, but clearly they didn't formulate it well so that #1 fits, too.
> "stuck in problem solving"? Hell, that's like half the reason I chose a career in computer related stuff.
I highly doubt you are referring to the same thing.
One thing is being challenged to present a solution. Another entirely different thing is being stuck with an impossibility when you are reaching a deadline and all your managers and peers look at you as if you're hopeless when in reality you're just working a workfront that is not practically solvable.
I've been in a project where I was assigned a task that was severely underscoped and was riddled with emergent blockers. The quick description of the task sounded like a trivial thing that could be done in a couple of days, but in the end it turned into a months-long, multi-team effort. I was a few weeks into the project when another engineer was tasked to help me out, in the spirit of "let's pull this idiot out of the mud because this is getting embarrassing". It took a week or so for that engineer's mood to change from "here I am to save the day" to "please someone, anyone help me".
Does this sort of scenario fit your "problem solving" ideal, where everyone just loves the whole experience? I highly doubt it.
One of the key factors in happiness and fulfilment is the sense of mastery and performance. Sometimes we need to shift to a lower gear to move over bumps in the road. Sometimes we find ourselves in the depth of a gorge with no possible way out. The latter leaves everyone miserable.
The example I gave had absolutely nothing to do with incompetency. It just so happened that the problem manifested as a sequence of time-consuming blockers which could only emerge once the previous one was unblocked.
Regardless of the example,the point is that it's naive and very ignorant to portray all blockers as feel-good "I overcame a challenge" opportunities.
Sometimes you feel good because you managed to jump a hurdle, sometimes you feel bad because you're stuck in the middle of a ravine with your arm crushed by a huge rock and the only tool you have is a pocket knife. Sure, you exercised your problem-solving skills on both scenarios, but they are hardly on the same level in terms of personal fulfilment and happiness.
It seems like the “problem solving” issue in your particular case and the paper in general is really an obvious thing. It’s ultimately the value generation of the engineer. It makes sense that the actual work would be the worst part! You simply gave an example where the core value generation has some spicy additions (“time pressure”, “unclear problem”, etc.).
> Does this sort of scenario fit your "problem solving" ideal, where everyone just loves the whole experience? I highly doubt it.
For me, yes. IF you remove the manager constantly asking "is it done yet" and "why isn't this done".
I like having and solving large, unscoped, deeply technical, problems as long as the nagging doesn't happen. My last launch (this month) was a 6 month long 3 team project that no one but me understood. It's now a documented feature, with unit tests, and it is extremely simple. In fact, one of my CLs which took ~2 weeks to make was adding 1 `if (X) { continue; }` and I sent that to my manager as "look at this amazing milestone we crossed" and him not getting it :)
Eh... yea, but as with any other creative profession (3d artist...), not all people get to do "fun" stuff often enough for the job to not become frustrating / boring.
Yes, programming itself really is fun, but only if you care about the thing you're working on (which most of us will for our own personal/side/business projects, but not that many of us work on exciting stuff in our 9-to-5).
I mean... You can only do so many years of repetitive coding tasks in a typical corporate environment. That's why so many senior devs (upper 30's and 40's) either move to a management position or quit the industry ("quit" as in they start working for themselves in their own business or they just do something different and maybe do contract work from time to time).
Personally, I can't imagine myself doing the corporate worker drone programming for much longer (10+ years has been more than enough), I want to stop some time in not too distant future and I'm actively working towards that goal.
Gluing things isn't really all that easy. I was unaware of how many different types of glues there are, their different strengths and weaknesses, which materials can and cannot effectively be glued, which pairings you might want for aesthetic vs. functional reasons, which kind of glues can't be used in the presence of other factors, different strengths, the amounts that have to be used, implications on health and safety (e.g. is a glue strong enough to do x for y time).
I've seen software engineering described as 'complexity management' and I think that gets closer to it than purely the use of other libraries which is commonly called just 'glue'.
All of these issues are mismanagement symptoms in my experience. Complicated tasks that are described with one line in broken English. Cryptic bug reports. The list goes on and on.
"The happy-productive worker thesis states that happy workers are more productive"
Yes, but that's not because I am happy all the time while working. It's because I have a purpose in life and a family that keeps me happy. Trying to optimize work to be a place to increase happiness sounds equally promising as breeding dogs whose shit smells like flowers.
"Psychological disorders such as job burnout and anxiety could also be reduced by limiting the negative experiences of software developers"
I fully agree there, too. I've fired highly profitable clients in the past, simply because their behavior (mostly too emotional, too chaotic, bad management, no time planning skills) was making our entire team unhappy.
Quote from the paper: "I also thought of situations where I’m debugging some issue with the code and I can’t figure out why it isn’t working – when it seems like everything should work, but it just doesn’t. This is definitely one of the
biggest gumption traps I encounter"
I totally don't get that one. For me, the path towards finally figuring out a challenging problem is the single most exciting thing in my job. This is precisely WHY I became a software developer.
I'm truly surprised to hear that, apparently, many of my peers despise this aspect of the job.
Of the 219 factors causing unhappiness, I'm guessing 218 of them are 'constantly changing requirements' :) The last one is 'nobody refilled the coffee machine.'
The #1 source of unhappiness for me today is lack of clear and direct communication. We are a fully remote team, so this is quite a problem.
I am honestly not sure how to improve matters at this point. I tried to lead by example to little avail. E.g. "look at how I documented that kind of issue here as a guideline moving forward". We tried issue templates that are effectively a checklist of required information, but not every problem fits into a round hole. Many (most?) are actually quite odd-shaped once you apply nuance and context.
There are also those really annoying interactions in Teams where someone will type out "you have a minute?" instead of just describing what they need someone's attention for up front.
At some levels, I wonder if I might have the wrong team for this kind of job. How does HN deal with team members who have trouble slowing down and communicating their thoughts well?
> How does HN deal with team members who have trouble slowing down and communicating their thoughts well?
At my work we have these "catch up" meetings where theres no agenda, time limits or minutes for our meetings. Every one in the team puts down tools and we take turns ranting about what ever is on our mind at that point, after 2-3 hours the meeting is over and we all go back to work with less time or understanding.
Being stuck is part of the job. Most of my unhappiness stems from a few things:
1. Time pressure. I can't develop code that works right. I am not talking about perfect performant portfolio work but as a backend developer many times I can't even hit the minimum standard of code quality because everything always needs to be done yesterday. Then I am responsible for it, and all the problems caused by deadlines are my problem, and every manager forgets they assigned me the deadline.
2. Pagerduty. Absolute worst thing to ever be perpetrated on development teams. It allows the C-levels to run "lean" teams because 4-8 developers rotate minimum 12/5 shifts, usually 24/5. 30 years ago this might have been necessary. We have been able to stagger timezones for the last decade now easily.
3. The work. It took me 10 years to land (by chance) a company with work that is interesting to me. My bar for interesting is so low at this point that on a scale of boring to life changing something that even remotely has me write other than boilerplate scores pretty high. Even now, I am responsible not only for the software but also for the devops (this is not a small company) which inevitably gets blocked to death by SREs, code review on another 2 repos for deployment, my own QA, etc. I do, effectively, the work of 4 different positions. I am paid for being a developer. Either raise my salary 40% or I will start dropping tasks.
Remote work has been an absolute boon to me. I am unsure how anyone could take a negative stance on it. Sure I don't talk to people often but I don't honestly care. Work has always been work to me. Coworkers are not your friends and honestly they probably shouldn't be. Find meaning in your life elsewhere. With remote work I can actually do my job (program) instead of being in meeting after meeting where a PM waxes poetic on whatever is important to them in order to justify their meager existence at the company. I no longer have to listen to the CEO go on for hours about how good the company is, or feel like I have to join in for beers instead of going to do what I actually want, etc. Fuck everything about the office. I am fully convinced this is not an "extrovert" vs. "introvert" battle, but rather a battle of people who have actually woken up the realities of being a serf vs. the people who remain asleep suffering from stockholm syndrome.
136 comments
[ 3.3 ms ] story [ 214 ms ] thread"a 60 minute meeting where no decisions are made because everyone just shouts at each other so you leave with a headache"
to "a 60 minute meeting where no decisions are made because everyone just shouts at each other but you can turn down the volume on Zoom"
It sounds really stupid, but that literally helped make a giant difference.
This last week was the funnest in a long time. A colleague who works at an office 7000 miles away flew in the for the week so everyone on team locally came into the office this week. First time in over 2 years I've seen everyone there. It was really fun.
If you need other ppl company to fill the emotional emptiness - dont work remotely.
Its more for the ppl who work task based or hourly based consulting and are free to do something else after.
If home isn't fitting for you, try anywhere else on Earth. There are probably new environments that are possible that have not yet been created. Let's explore those. It's very likely that the office isn't the single best place on Earth.
> "The happy-productive worker thesis states that happy workers are more productive. Recent research in software engineering supports the thesis, and the ideal of flourishing happiness among software developers is often expressed among industry practitioners..."
'Recent research in software engineering...' now, what does software engineering research have to do with emotional psychology, again?
Psychology of labor is a thing, and has been for ages. The idea behind it is simple: it's people with a mind that do the labor, so their psychological state has influence on the work done. Is it software engineering? No, but the article purports to identify factors that influence the psychological state during software development.
That said, I do believe such studies to be of minimal value. Voluntary surveys are absolute bottom of the barrel. Identifying 219 factors from such a study seems like analysis gone mad. The extensive discussion of the non-normality of the central happiness statistic seems a point in case: it's trivially visible, it's not interesting, and doesn't play a role in any further analysis or conclusion. They do remark that the mean value they find is higher than in other studies, but can't explain it. Not that they need to, because nothing would change in the paper if the value had been lower.
Basically, this looks like an experiment from a starting PhD, who needs to push out one paper per year. Sadly, it isn't. The authors are senior researchers, who seem to have little idea of psychology.
The 3 key ingredients to motivation are: autonomy, mastery, and purpose.
Nearly every time I've been unhappy writing software it has been because of a deprivation of autonomy, mastery, or purpose.
I've been ordered (deprivation of autonomy) to work on things I didn't think mattered (deprivation of purpose) with a language I wasn't familiar with in a context I wasn't familiar with, in a way I thought was wrong (deprivation of mastery and autonomy) for political rather than technical reasons (deprivation of purpose). I have never been unhappier and less motivated than that.
There exists negative motivation. If you have $50k in credit card debt, you are very motivated to pay off that debt, but you are neither happy to have the debt nor happy to pay. You just plan to be more happy when it's over.
This kind of motivation can also be present on the workplace, along with positive motivation (when you are happy about something and want more of it).
Robert Sapolsky (Stanford Professor) has said:
> If I had to define a major depression in a single sentence, I would describe it as a "genetic/neurochemical disorder requiring a strong environmental trigger whose characteristic manifestation is an inability to appreciate sunsets."
I think engineers are hyper competent can do individuals with deep belief in possibility & potential. Few organizations can match & support this vanguard fleet well/at all. A corporate entity can very rarely accept & permit itself to support something far beyond it's grasp. It has to be willing to negotiate & work with people who know more & have more insight than it can. Almost no corporation can find that humility. They cant accept their own limitations/ignorance & trust/enable.
There's some org blame possible in this list. But all masked/hiddenz said in typical corpspeak to protect the guilty non-technical cant-knows.
Am I the only one who loves this? My main complaint about my day-job has typically been that the problems are too boring and easy.
that’s the difference of devs that stay motivated and happy
even ones that don’t have pressing monetary concerns are just skittish sometimes. those folks can productive but boy do they look miserable.
kill the fear and the stuck problems become less of a thing
This has never happened for me the closest I have gotten is that I have to give the client to option of sticking to our initial plan or change it for the expense of more time and money.
I wouldn't really call that being stuck with a problem tho, its more the client is stuck with a decision they don't want to make.
It's a little unfortunate the paper doesn't go deeper into this beyond a few lines:
>As one respondent commented: “I feel negative when I get really stuck on something and cannot get around it”. Another respondent elaborated: “I also thought of situations where I’m debugging some issue with the code and I can’t figure out why it isn’t working – when it seems like everything should work, but it just doesn’t. This is definitely one of the biggest gumption traps I encounter”.
To me, the most annoying part isn't just getting stuck, but getting stuck in conjunction with the (lack of) complexity of the issue in theory, and the time pressure (#2 on the list). A lot of problems just shouldn't take as long as they do, but communicating with frameworks, other people's code, poor assumptions (#3?), weird requirements definitely make problems a lot more difficult.
The majority of the work is just trivial plumbing in theory. It's not some complex algorithm. Yet the complex algorithms are often documented far better, you're given more time, and at least personally, it's a whole lot more interesting to work with than fighting a Frankenstein application just to do something extremely minor like conditionally changing font colors.
Often times most of the issues from the list are all caused by incompetent management:
- Time pressure - management f/u deadlines
- bad coding and quality - management hired coding monkeys
- under-performing colleague - why not fired already ? Management
- Feel inadequate with work - picking wrong ppl to do the job
- mundane and repetitive tasks - management gives no time on automation
- unexplained broken code - same as bad quality
- imposed (often artifical) limitations on the devs - who makes those decisions?
—-
More than half of this list is cause by incompetent management / bad decision making.
—-
Personal advice for ppl suffering due to those issues - find a better boss.
* Managers create all the problems,
* Problems not created by managers are created by my team members,
* Everyone around me is incompetent except myself,
* The problems I create have everyone else to blame but myself, because I'm flawless and I was just put in a bad situation.
* goto start.
I've been in a fair share of time-constrained problems, but honestly deadlines tended to slip because of a mix of emergent technical requirements that dev teams didn't managed to see beforehand, and scoping tasks that severely undershoot the requirements. Scoping and planning is hard, specially with limited info, and you can't reasonably allocate 10x the resources to your project just to have a decent slack in the critical path.
Also, bad code can and often is subjective,and I've seen competent and above-grade engineers underperform because of task- and life-specific issues.
It's high time that developers cease the "everyone around me is incompetent and responsible for al problems" mindset.
Also, we are for some reason blessed with management with not much soft skills. Stuff like new manager coming in and insulting people right and left on the first day with no reason just because they are insecure or arrogant is frequent too.
There are good manager, I worked with some. But bad management is frequent and there is very little accountability for managers, so they get stuck for years and decades.
Make things more open-ended so you can change things later? Too risky, too time-consuming. All frameworks, methods, etc. used become increasingly more closed off, and fixing them after the fact is an afterthought. 2 years later something that should take 2 hours now takes a week, but who cares.
Hiring weaker individuals when your codebase has no obvious flows? Clear signs of executives, HR managers etc. pinching pennies. Don't set people up for failure, and use stronger individuals to create environments where weaker individuals are set up for success instead. This is leadership and teaching 101.
No slack in the team? No time to work through codebase problems. Most of all, assumptions that there will be no slack cause the team to become so skeptical, they won't even mention long term issues. It creates the very mindset they claim to dislike: one where mercenaries shine, getting a quick buck and not caring about the feelings of those coming after them.
The only thing I don't agree with, is not matching individuals. There just isn't enough interesting work for the entire software developer crowd to go into. CRUD-plumbing webdev rules the world, it is extremely unimaginative but it pays well. Ironically, having the entire industry take a breather and look at the problem from a higher level might be the thing to make it more interesting and less painful, but I doubt there will ever be enough jobs in the more complex, visual, animated and/or hacky fields anytime soon to accommodate all the developers now stuck trudging in the stereotypical CRUD webdev shop.
I say this knowing someone from a different, non-management discipline will run into the same issues while working in a software team. UX, UI, graphics artists, testers, etc. all suffer similarly from management incompetence.
They are, but the first line of defense is often broken due to problems that are controlled, if not outright created, by developers.
I mean, isn't feedback from developers the main source of info available to a manager? What if that info becomes highly unreliable due to natural occurrences like emergent requirements? What happens to a schedule when midway through the project someone realizes there's something fundamentally broken with the architecture put together by the developers and suddenly you need a major rewrite to be able to meet your requirements?
Don't confuse accountability with responsibility. Managers are held accountable, but developers can and often are responsible for misdirections and blockers and the need to rework.
Trying to pretend that the role of a manager is a Dickensian figure whose purpose in life is to rain misery on developers, who are perfect and flawless, is not a honest starting point for a discussion on unhappiness of software developers.
Then why is that feedback routinely thwarted or ignored in so many places? You make it seem like developers aren't giving feedback. Most places I worked at, at least 1-2 developers in a team of 7-8 were passionate enough initially to provide feedback. Then their feedback gets shot down repeatedly for no other reason than "low priority". What do you think happens to people who have to make a conscious effort to document such issues, articulate them and provide potential solutions? They figure "you know what, this isn't worth the effort, it won't get picked up". That's valuable time they could spend coping with their frustrations instead of hopelessly tackling them head-on.
Managers are held responsible because when we speak of managers, we're not just talking about middle managers. We're talking about all managers, including the executives. If those executives prioritize short term sales over long term company health, don't be surprised when your ICs follow your example. If you're a leader, set the example you expect others to follow.
>What if
"What ifs" are primarily exceptions. How about we tackle the vast majority of cases where short term financial gains are prioritized over long term company health? That's where the feedback matters most for passionate ICs, and that's where feedback is waved away the most.
>Trying to pretend that the role of a manager is a Dickensian figure whose purpose in life is to rain misery on developers
You're the one claiming this. Don't take us all as not understanding the point of view of executives. Understanding doesn't mean agreement, nor does it mean the chickens won't come home to roost someday. If you consciously decide it is worth making your codebase a complete mess for short term gains, don't cry when in 5 years, all that's left is a bunch of jaded developers only in it for the money wondering why it takes them ten times as long to fix something trivial.
In my 15 year career I’ve never seen line manager being let go for poor performance. I’ve seen a good number of underperforming devs getting canned and some higher-ups (usually for political reasons or just phoning in completely) but never line managers.
Of course it is, that's well-known.
But for 20 years of career 99% of all managers I ever worked with outright ignore the feedback.
Most people should not be in positions of power -- ever. It quickly turns into an ego trip where inconvenient facts are ignored and hand-waved away. And always letting somebody else deal with the fallout of your incompetence.
Programmers are not stupid. With your feedback routinely ignored you learn to keep quiet -- why expend energy on something futile? Or you change jobs.
Take a wild guess which of both happens 90% of the time.
I deliberately stayed at that level, even though I could have easily bubbled up higher.
I felt that I could make a big difference to my team, and, by running a good team, make a big difference to my company.
There were a lot of problems in the corporation; bad decisions, HR issues, administratium poisoning[0], etc., but the consensus seems to have been that my little team was really quite effective, and I kept engineers for decades.
Managers can make a big difference for the positive.
[0] https://www.mit.edu/people/dmredish/wwwMLRF/links/Humor/Admi...
Do you tell a painter to get it done by Monday?
That's why small iterations are there in the first place: to constantly add incremental value, not "big bang" plan-the-work and work-the-plan but reacting to change.
Sure, an artist can have leeway for their creative efforts. But allowing artists to work on a muse-driven timeline is also why the stereotype of a "starving artist" exists.
Engineers on the other hand have some product with at least a baseline of utilitarian value. Those generally need timelines because somebody is planning on a delivery of that utility.
But I think both those are besides the point. You can have a structured process that also integrates creativity. I think treating them as mutually exclusive is a false dichotomy.
I reckon there’s some selection bias here too, people who perceive themselves to be incompetent probably talk about it less.
The issue here is not what's the true skill level of anyone in the team. The problem is this recurrent theme of software developers demeaning everyone around them while portraying themselves as flawless saviours.
A key trait of software development is JIT onboarding and continuous development. If you develop your skills and today you're a better developer than you were yesterday, that means that yesterday you were a worse developer and quite possibly quite bad by your measuring stick from some point in the future.
Thus if JIT onboarding and continuous personal development is a basic aspect of software development jobs, why is not being ab absolute expert on everything the target of so much criticism and abuse?
I often look to the work I've done in the past and often times I come across less optimal choices that today I wouldn't make. I'm sure the only ones who don't experience the same are thise who learn nothing from anything. Therefore, why use that as a target for abuse?
This is a horrible trait and a recipe for painting oneself into corners unless you are only working on trivial stuff that's been done before.
Most of us are decent enough at our jobs, and generally the industry does a good job of weeding out those who can't perform or they end up lost and irrelevant in some big company. There are certainly some bad developers out there, but there's bad doctors, bad lawyers, etc. in the real world too.
That said, the impact a bad manager can have is definitely of a greater magnitude than a bad engineer, generally speaking.
People are generally good and want to do a good job and be recognized by their peers.
Different people have different strengths and skills. It’s the sum of those things that makes a team. Alone we could do some of the things we want to achieve but it’s together that we can make it happen.
In particular I’ve seen situations where every single person is working hard doing their job in a defensible way, but the code base is heading towards a cliff because no one has the incentive and/or skill set to point out that the short term decisions made on either side of the engineering /product divide are steadily inching us towards a state where the code base will be too complex to add a feature or fix a bug without creating more bugs.
Ultimately this type of problem has to be owned by management with support all the way up the chain in order to be solved. That doesn’t mean ICs and PMs don’t have a role in the solution, but this is why engineering management is hard and requires technical depth.
Tearing down a straw man is not an impressive feat.
The inconvenient truth is that a lot of programmers are just not that good. They lack the self-awareness, insight and experience to look into the near future and realize they're contributing to the problem.
I was there too. Facepalmed really hard after I realized it years down the line.
Neither is being cynical.
Everyone is at a different point in their life and has different skills and has the potential to do good work.
I don't know what problem you're referring to. Maybe you could enlighten us and tell us what it is about self awareness, insight, and experience and gazing into crystal balls that make developers, "good."
You seem to attribute spaghetti code to a personal failure to have characteristics you think are essential. How’s anyone supposed to live up to that?
I have a different theory. I think that it’s a combination of things which cause spaghetti code. I agree with others here that poor management is a strong factor. Also poor communication, time pressures, vague specifications, insufficient proof or testing, a lack of documentation, family emergencies, lack of motivation, general anxiety, social dysfunctions on the team, and so on.
Everyone I’ve worked with usually had something going on for them. Even if they were just starting out or changing careers or had been at it a while but felt like they weren’t getting anywhere.
The bad developers, to me, were the ones who brought others down when they could have raised them up.
Can we live up to that? Absolutely, but it takes time, practice and a lot of screwing it up -- so, sadly, it can't happen with people who are still kind of fresh. Sad fact but what can you do. I made my peace with it, begrudgingly.
Its not “on purpose” by those devs, but its hard to argue it was a sane decision by management.
To spend the time and effort to write robust, maintainable software would slow them down and give away their niche to a competitor. So it makes sense to hire decent people and toss code at the wall until they find that niche.
Other businesses in industries like security or real-time systems prioritize and value different things. There's usually more of a focus on performance and reliability. That means longer development timelines but the cost of failures is much higher.
If the technical debt is big enough it can cripple the growth of the company to the point a competitor that initially was behind -> gets ahead.
I can give one example in map making industry - TomTom vs Here in EU.
I completely agree with you. Thing is - not everyone can do that.
Thats why top companies hire best talent and not anyone who applied.
Thats why there is a canyon size difference in compensation between one “expert” engineer and another EXPERT engineer.
It sounds like elitism, thats just how it is.
Why not? If you don't have an accurate understanding of the problem you NEED to allocate extra time to gain that understanding or redevelop as the requirements emerge.
> emergent technical requirements that dev teams didn't managed to see beforehand
What? So developers that see poor breifs and ask for more time to manage that lack of information can't be given that time but then its the developers problem for not asking for more time to manage that?
Your developers don't have a crystal ball!
It's high time that Management stop blaming developers for the things managers control.
Are managers at fault for all problems? Intuitively I would very much doubt that’s true of any project anywhere.
Are managers responsible for all problems? It depends on the environment and level of autonomy but.. kinda, yeah. The first rule of leadership is that everything is your fault.
You kind of have to pick which one you want to define “to blame” as here, but I’m tempted to stick with the latter, if only because I don’t know of a lot of managers that had guns put to their head to take the job, and my own experience tells me that the pay disparity usually covers it.
At least try to be honest with yourself, plz.
Thanks for this.
If you are in a personal relationship that works, you will know that any successful team boils down to the interaction between the members of that relationship.
To blame one party, is immature IMO, even if objectively there might be some truth to it.
In any team situation there will be humans involved who have shortcomings - even the top all-rounders have them.
The ways that other team members can react to those shortcomings are multifold. There are ways of reacting that bring out the strength of the other members and hence create a stronger team overall.
It requires a common understanding of- and focus on- the common goal. If a team member furthers his own goals only, they are the problem and not the possibly imperfect manager, for example.
Thankfully, nobody could constrain me in my open source work. I (with the help of community members) built:
- SocketCluster (https://socketcluster.io/): A distributed pub/sub framework.
- Capitalisk (https://capitalisk.com/): A lightweight quantum-resistant blockchain which is less than 5K lines of code.
- LDEX (https://ldex.trading/): A deterministic decentralized exchange (DEX) which can work with many different blockchain protocols. It's less than 4K lines of code in total and only has 3 small third-party dependencies (including sub-dependencies).
> under-performing colleague - why not fired already ? Management
Everybody underperforms once in a while. With enough coworkers, there are always a few on that bracket, even if no one is incompetent.
> Feel inadequate with work - picking wrong ppl to do the job
You are the one that controls how you feel and what jobs you accept. Are you complaining that management hired somebody for doing a job that they need done?
But indirectly, a lot of times management causes those issues by adequately responding to market needs. The world sucks, and while managers do create a lot of problems by themselves, they didn't create them all.
If something is important and I don't feel hugely guilty if I fail, I will enjoy time pressure.
Repetitive tasks can be amazing, analyzing the patterns and optimizing them away is a cool exercise. It hurts when people forbid you to do so ("don't write a script for this" "why are you changing this to do it your way, it's not right"). Same for imposed limitations.
Underperforming colleague is only an issue is if it's unspoken, not discussed or imposing secrets on you. If my colleague is slow then I want to reallocate the efforts so I can do a bit more to avoid him dragging down the team, and I just don't want the manager to bother me with slow perf if there's a slow guy nor I want that slow guy to force me to lie so he can stay his way. It just has to be open and optimized.
Unexplained broken code requires a shift in thinking: freedom to break it, freedom to get time to do so. You need to reverse the context, system and desired outcomes to improve understanding and fix it.
Another aspect is that I think adult life removed a lot of important emotional layers: no more open challenges that tame into natural competitiveness, that unleash positive pressure and brain activity leading to learning with more fun. A lot of jobs devolve into politics. Quite often I've heard people tell me "shh don't tell we're done so we can slack a bit". From the smallest jobs to highly paid engineer.. same behavior occurs. Kinda creates low levelling.
That's not a bad thing per se. However, management always fails to account for e.g. mental fatigue after finishing an important milestone that most of the time has been grinding hard at for the last month.
That fatigue needs a week or so to disappear by itself -- just getting one good massage, sex and sleep doesn't fix everything. If you're loaded with work again starting tomorrow you'll do a sloppy job and will keep accumulating more fatigue.
I'm not saying an army of unmotivated lazy slackers doesn't exist out there. It absolutely does. But not everyone is like them. Sometimes people really do need to relax a bit in order to recover their ability to be useful to the business.
Our stupid system of requiring 8h a day for 5 out of 7 days misses 99% of all human specifics and it simply doesn't care. That's not okay.
Is this a real thing? I have never known there to be a technical problem in work that I wasn't able to solve, all of my problems have been from ever changing requirements and clients refusing to give detail.
Is there a role for me that maximises technical complexity and minimises managements role?
Half a year later, it will be discussed again. The odds of the issue being picked up are higher, but still not high enough. The same song and dance is performed, only for the issue to be put all the way down on the backlog, the place where issues go to sleep forever.
I didn't become a software engineer to write yaml or negotiate K8s resource allocation.
I also argue that we're probably fucking it up a lot, causing it to be more painful than it needs to be, but that's because we consistently get our developers to do infrastructure work.
A corollary to this, locally running the code AND integrations is essential. If you don't have the ability to replicate the full system locally, your devs are hamstrung and will take much longer to solve what could be very easy problems if only they could have debugged it locally and quickly. This is related because if your infrastructure is shooting for the moon in complexity, your devs have little hope of replicating it locally.
The perversion of it is that it comes across that I’m against DevOps. I’m absolutely the opposite. I’m against attaching bullshit marketing labels to good practices and making them a cancer on the project (cough devops, agile cough).
I’ve dealt with this recently. The “DevOps guy” was a toxic, condescending gatekeeper who wouldn’t co-operate with the engineers at all, but had the ear of the management.
He had a bunch of servers and builds he was really pleased with that were not at all documented and completely useless to everyone, because no-one understood it and couldn’t ask questions.
Good ops should be utterly transparent and utterly out of the way. Not hidden magic, just so easy to understand that it ticks over doing what it does without interrupting your workflow. And always reproducible locally.
Give a prick even the slightest chance to poison your company and they will is about the only 100% reliable piece of advice I could give anyone in this industry.
There is absolutely no bullshit in replacing waterfall's big upfront design and risk-prone one-shot dev project with an iterative process where at each cycle you reevaluate your course and your planning, always based on developer feedback.
There is also absolutely no bullshit in avoiding the mistake of artificially separating the devprocess into sysadmin stuff and dev stuff, and actually get developers directly involved and more importantly become mindful of the reality of everyday operations.
Portraying agile and DevOps as bullshit is clear telltale sign you are completely oblivious to the issues software developers face on a daily basis, and how agile and DevOps help solve or mitigate them.
2) agreed.
3) I never did that. I’m fully aware of the issues software developers face on a daily basis. I am one. Same as almost everyone here. Agile and DevOps (capital A, capital D, capital O) are corrupted buzzwords used to saddle engineering teams with snake oil salesmen and deeply suspect printable credentials.
But by all means you keep on throwing around baseless aspersions about who has the right or wrong kind of experience if they say something you don’t like.
Seems to me like in many places, career success is mostly driven by metrics that are not related to good software engineering practices (specifically showmanship). Normally I would expect success to be measured primarily on metrics closer to the actual professional skillset.
Not arguing for or against, just surprised not to see it in the list.
It's different at the team level, but nobody's really cracked it for individuals yet that I'm aware of.
I much more understood the “happiness” to be constrained to how you feel about work. There’s no mention of happiness outside of work.
- Junior developers who can't get their code pass code review process
- Senior developers who don't know what's going wrong in a microservice products. Rabbit holes are everywhere where you don't know where, who, how to fix the bug in a strange service.
- PM who can't write clear JIRA tickets
> “I feel negative when I get really stuck on something and cannot get around it”. Another respondent elaborated: “I also thought of situations where I’m debugging some issue with the code and I can’t figure out why it isn’t working – when it seems like everything should work, but it just doesn’t. This is definitely one of the biggest gumption traps I encounter”.
Here's a contrived example.
Let's say you became a house builder because you liked building houses from scratch. In a few years you find yourself working for a company and you are the window frame expert. You calculate, design, draw windows for the bespoke houses. You also make sure they fulfill building regulations. All day long. Note that you don't get to make the windows, other guys in the company do that.
Then you realize that this is not what you had in mind when you wanted to become a house builder. But the company pays you very well and you have some nice co-workers. You need to leave but you don't.
We can argue about the specifics, but stuck in solving that type of problems (especially if it's for incompetent co-workers) can drive you mad in the long run.
2. "stuck solving problems pushed onto me" Oh wow, how I hate that. Like when a user f*cks up their account on a Friday evening because they mixed up the "Delete" and "Rename" buttons (how do you do that? they are even color-coded..) and of course they have an urgent deadline so now instead of going home early to enjoy the sunshine I have to clean up this mess. And of course it's always the big important clients who employ cheap unskilled employees, so of course their mess gets triaged as critically important.
I believe the study intended to poll for #2, but clearly they didn't formulate it well so that #1 fits, too.
I highly doubt you are referring to the same thing.
One thing is being challenged to present a solution. Another entirely different thing is being stuck with an impossibility when you are reaching a deadline and all your managers and peers look at you as if you're hopeless when in reality you're just working a workfront that is not practically solvable.
I've been in a project where I was assigned a task that was severely underscoped and was riddled with emergent blockers. The quick description of the task sounded like a trivial thing that could be done in a couple of days, but in the end it turned into a months-long, multi-team effort. I was a few weeks into the project when another engineer was tasked to help me out, in the spirit of "let's pull this idiot out of the mud because this is getting embarrassing". It took a week or so for that engineer's mood to change from "here I am to save the day" to "please someone, anyone help me".
Does this sort of scenario fit your "problem solving" ideal, where everyone just loves the whole experience? I highly doubt it.
One of the key factors in happiness and fulfilment is the sense of mastery and performance. Sometimes we need to shift to a lower gear to move over bumps in the road. Sometimes we find ourselves in the depth of a gorge with no possible way out. The latter leaves everyone miserable.
why judge yourself for others incompetency?
Regardless of the example,the point is that it's naive and very ignorant to portray all blockers as feel-good "I overcame a challenge" opportunities.
Sometimes you feel good because you managed to jump a hurdle, sometimes you feel bad because you're stuck in the middle of a ravine with your arm crushed by a huge rock and the only tool you have is a pocket knife. Sure, you exercised your problem-solving skills on both scenarios, but they are hardly on the same level in terms of personal fulfilment and happiness.
For me, yes. IF you remove the manager constantly asking "is it done yet" and "why isn't this done".
I like having and solving large, unscoped, deeply technical, problems as long as the nagging doesn't happen. My last launch (this month) was a 6 month long 3 team project that no one but me understood. It's now a documented feature, with unit tests, and it is extremely simple. In fact, one of my CLs which took ~2 weeks to make was adding 1 `if (X) { continue; }` and I sent that to my manager as "look at this amazing milestone we crossed" and him not getting it :)
Yes, programming itself really is fun, but only if you care about the thing you're working on (which most of us will for our own personal/side/business projects, but not that many of us work on exciting stuff in our 9-to-5).
I mean... You can only do so many years of repetitive coding tasks in a typical corporate environment. That's why so many senior devs (upper 30's and 40's) either move to a management position or quit the industry ("quit" as in they start working for themselves in their own business or they just do something different and maybe do contract work from time to time).
Personally, I can't imagine myself doing the corporate worker drone programming for much longer (10+ years has been more than enough), I want to stop some time in not too distant future and I'm actively working towards that goal.
- "Being stuck in, problem solving": great, fantastic, hooray, woo, yay, hoopla
- "Being stuck, in problem solving": not so much
- I had to help my uncle Jack off a horse
Yes, in the end the customer will be happy. But you spent 99% of your time glueing stuff and 1% of your time thinking about what to glue.
I've seen software engineering described as 'complexity management' and I think that gets closer to it than purely the use of other libraries which is commonly called just 'glue'.
Complexity management is a nice name. But again, it's only 1% of what you think about in a typical job. The rest is applying duct tape and glue.
Yes, but that's not because I am happy all the time while working. It's because I have a purpose in life and a family that keeps me happy. Trying to optimize work to be a place to increase happiness sounds equally promising as breeding dogs whose shit smells like flowers.
"Psychological disorders such as job burnout and anxiety could also be reduced by limiting the negative experiences of software developers"
I fully agree there, too. I've fired highly profitable clients in the past, simply because their behavior (mostly too emotional, too chaotic, bad management, no time planning skills) was making our entire team unhappy.
Quote from the paper: "I also thought of situations where I’m debugging some issue with the code and I can’t figure out why it isn’t working – when it seems like everything should work, but it just doesn’t. This is definitely one of the biggest gumption traps I encounter"
I totally don't get that one. For me, the path towards finally figuring out a challenging problem is the single most exciting thing in my job. This is precisely WHY I became a software developer.
I'm truly surprised to hear that, apparently, many of my peers despise this aspect of the job.
Has anyone tried to replicate that results, with preregistration of study? What was the outcome?
edit: speeling
> 152 Time pressure
I can deal with the 1st as long as the 2nd doesn't become 1st.
And there lies its problem.
I am honestly not sure how to improve matters at this point. I tried to lead by example to little avail. E.g. "look at how I documented that kind of issue here as a guideline moving forward". We tried issue templates that are effectively a checklist of required information, but not every problem fits into a round hole. Many (most?) are actually quite odd-shaped once you apply nuance and context.
There are also those really annoying interactions in Teams where someone will type out "you have a minute?" instead of just describing what they need someone's attention for up front.
At some levels, I wonder if I might have the wrong team for this kind of job. How does HN deal with team members who have trouble slowing down and communicating their thoughts well?
At my work we have these "catch up" meetings where theres no agenda, time limits or minutes for our meetings. Every one in the team puts down tools and we take turns ranting about what ever is on our mind at that point, after 2-3 hours the meeting is over and we all go back to work with less time or understanding.
1. Time pressure. I can't develop code that works right. I am not talking about perfect performant portfolio work but as a backend developer many times I can't even hit the minimum standard of code quality because everything always needs to be done yesterday. Then I am responsible for it, and all the problems caused by deadlines are my problem, and every manager forgets they assigned me the deadline.
2. Pagerduty. Absolute worst thing to ever be perpetrated on development teams. It allows the C-levels to run "lean" teams because 4-8 developers rotate minimum 12/5 shifts, usually 24/5. 30 years ago this might have been necessary. We have been able to stagger timezones for the last decade now easily.
3. The work. It took me 10 years to land (by chance) a company with work that is interesting to me. My bar for interesting is so low at this point that on a scale of boring to life changing something that even remotely has me write other than boilerplate scores pretty high. Even now, I am responsible not only for the software but also for the devops (this is not a small company) which inevitably gets blocked to death by SREs, code review on another 2 repos for deployment, my own QA, etc. I do, effectively, the work of 4 different positions. I am paid for being a developer. Either raise my salary 40% or I will start dropping tasks.
Remote work has been an absolute boon to me. I am unsure how anyone could take a negative stance on it. Sure I don't talk to people often but I don't honestly care. Work has always been work to me. Coworkers are not your friends and honestly they probably shouldn't be. Find meaning in your life elsewhere. With remote work I can actually do my job (program) instead of being in meeting after meeting where a PM waxes poetic on whatever is important to them in order to justify their meager existence at the company. I no longer have to listen to the CEO go on for hours about how good the company is, or feel like I have to join in for beers instead of going to do what I actually want, etc. Fuck everything about the office. I am fully convinced this is not an "extrovert" vs. "introvert" battle, but rather a battle of people who have actually woken up the realities of being a serf vs. the people who remain asleep suffering from stockholm syndrome.