Hacker News Reader

Comment by hayst4ck | Hacker News Reader

From the paper:

  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

View on HN

Im surprised that incompetent management is so low on this list.

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.

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.

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.

> People are generally good and want to do a good job and be recognized by their peers.

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.

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

Interestingly enough - its a business decision to hire 3/4 of the team of such ppl and then complain that the code produced is “a spagetti code”.

Its not “on purpose” by those devs, but its hard to argue it was a sane decision by management.

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.

Someone will still have to pay the price after the niche is found.

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.

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.

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.

[0] https://www.mit.edu/people/dmredish/wwwMLRF/links/Humor/Admi...

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

> Managers are held accountable

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.

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.

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.

Are they painting a house or are they painting portraits?

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

> It's high time that developers cease the "everyone around me is incompetent and responsible for all problems" mindset

I reckon there’s some selection bias here too, people who perceive themselves to be incompetent probably talk about it less.

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

> A key trait of software development is JIT onboarding and continuous development

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.

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.

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:

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

It takes two to tango.

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.

Hum... I disagree on many. More directly:

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

> - mundane and repetitive tasks - management gives no time on automation

Thanks for this.

>- bad coding and quality - management hired coding monkeys

At least try to be honest with yourself, plz.

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.

Y'all can't enjoy watching a sunset without being "motivated"?

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.

yeah there's an emotional threshold where you just can contemplate existence with a comfy mat of joy, even if totally passive and idle

Autonomy for sure is my main source of development happiness. It means that my employer trusts me that I don’t burn their business to the ground

>Being stuck in problem solving

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.

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.

I'm sure there are plenty of compromises in a construction project too, and time is one of them.

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.

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.

> Being stuck in problem solving

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.

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

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?

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

Oh no, the 'stuck'-problems are the best problems.

Only when you don't have a deadline and a few stakeholders asking for progress updates and time estimates.

In that case, I'm annoyed by the deadline and the stakeholders, not the problem.

fear is a mind killer

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

> 186 Being stuck in problem solving

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?

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.

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.

Reply on news.ycombinator.com