
Why your programmers just want to code - nreece
https://medium.com/maker-to-manager/why-your-programmers-just-want-to-code-36da9973388e
======
jdowner
A man is flying in a hot air balloon and realizes he is lost. He reduces
height and spots a man down below. He lowers the balloon further and shouts:
"Excuse me, can you help me? I promised my friend I would meet him half an
hour ago, but I don't know where I am."

The man below says: "Yes. You are in a hot air balloon, hovering approximately
30 feet above this field. You are between 40 and 42 degrees N. latitude, and
between 58 and 60 degrees W. longitude."

"You must be an engineer," says the balloonist.

"I am," replies the man. "How did you know?"

"Well," says the balloonist, "everything you have told me is technically
correct, but I have no idea what to make of your information, and the fact is
I am still lost.

"The man below says, "You must be a manager."

"I am," replies the balloonist, "but how did you know?"

"Well," says the man, "you don't know where you are, or where you are going.
You have made a promise which you have no idea how to keep, and you expect me
to solve your problem. The fact is you are in the exact same position you were
in before we met, but now it is somehow my fault."

\--

This is the sentiment that I see in the article.

It reads like someone who is not a software engineer criticizing software
engineers because they don't do what he wants. Sure there is a reference to
culture and that. But, ultimately, he wants software engineers to care about
business and market issues over software issues. He sees the software engineer
as an impediment to the problems he is trying to solve rather than someone who
tries to contribute through his domain of expertise. This situation is not
going to change by using the amateur psychology of not rejecting an engineers
ideas when they are starting out. That is insulting and, frankly, the heart of
the problem -- that he sees software engineers as children to be led rather
than peers who you can collaborate with.

~~~
marktangotango
_his “team-friendly” interactions were usually sarcastic. He often talked
about technical debt, our lack of innovation, and the “stupid” decisions
holding us back. An irritating “I told you so” sentiment plagued his comments
and feedback._

The easily missed point here is that Jamie, on some level, still cares. The
ones this author doesn't recognize are the ones who don't give any outward
sign of annoyance, because they genuinely don't care. They'll participate in
your "chaos is a process" and roll with your shifting requirements by doing
the bare minimum at all times. Maybe they'll throw in some stuff occasionally
to wow everyone, usually not. They'll just plug along, keeping their ideas and
improvements to themselvse, watching you fail. Because they've seen this all
before. Rare is the organization that knows what they want, and have
structures in place to effectively build and grow products. I've personally
seen it exactly once.

~~~
scruple
> I've personally seen it exactly once.

I've seen it twice.

I left the first company where I saw it (I stayed for 6 years and learned more
here than everywhere else else combined, despite the other problems) because
despite having all of these brilliant people and alignment with front-line
managers and other teams and strong process and strong product guidance the
company was ruled over by a tyrant in the CEO and CFO. The CFO only cared
about the bottom line and the CEO, too, but he cared more about taking full
credit for all of our engineering successes. The folks I kept in contact with
say not much has changed but that they've brought in some MBA types in the
form of senior managers and things have been doing downhill since.

The second time, I came in to the organization and it wasn't great but things
worked and we were solving real problems for real people and for some reason
it clicked well between the different groups/departments. Then the CEO and
board, in their eternal quest to go IPO, disrupted the Engineering upper
management chain, and we went through 3 different CTOs in the span of about 16
months. Suffice it to say, the magic was lost. That company is _still trying_
to go IPO, of course, and _still thinks_ they'll achieve it by bringing in
different executive management players, last I heard.

------
TeMPOraL
> _His concern for market share and business health is replaced with (...)_

> _His enthusiasm for changing the world is replaced with nit-picking the
> development process._

Here's your answer. It's because you hired the programmer based on technical
competence and not their attitude to servitude in business.

You get what you measure. You didn't disqualify me as a candidate because I
think your business is boring and I need the money. So don't be surprised that
I'll be doing my job as effectively as possible - which involves lots of lone
coding, unless your internal process is completely bonkers - but I ain't gonna
drink the kool-aid. Want someone with a more "professional" attitude? _Filter
for that during the interview_.

And that "changing the world" thing? That's just bullshit, and you're not
fooling anyone past their teenage years with that. You're not SpaceX. You're
not changing shit. Chances are, you're just trying to make money selling the
usual butt CRUD everyone else is selling too. If you hire smart people, don't
be surprised they know it's bullshit.

Programmers want to code because they're programmers. Chefs want to cook
because they're chefs. That's what they do. This article only shows hiring
laziness, coupled with usual complaining that the company isn't getting more
than it asked for.

\--

EDIT:

Ok, this article doesn't _only_ show hiring laziness. The point about how
vulnerable enthusiastic people are in the initial period is spot-on and I
agree with it. I wrote the above comment because I believe that the article as
a whole exemplifies additional lack of understanding of the perspective of
programmers, which can lead to extra post-interview disappointment.

~~~
toyg
_> You didn't disqualify me as a candidate because I think your business is
boring_

Er, I suspect this would make it impossible to staff 90% of positions in
programming. If I thought a business were exciting, I would be a specialist in
that business, not in programming - or I'd be a very lousy 9-to-5 programmer,
because my passion lies elsewhere.

Very few companies have the luxury of hiring passionate programmers who are
also interested in making the business succeed; most of them just want their
payroll system chugging along and someone to sort out their Excel when it
breaks.

~~~
TeMPOraL
> _Er, I suspect this would make it impossible to staff 90% of positions in
> programming_

Well, of course. So a typical company with a boring business[0] shouldn't
expect that people they hire will suddenly develop deep love towards the
company and the business it's in.

> _Very few companies have the luxury of hiring passionate programmers who are
> also interested in making the business succeed._

Exactly. Very few companies _need_ that luxury, too. That's why I'm saying
this article is an example of complaining about not getting more than one
should be getting. When you hire someone to do the job right, you require them
to do the job right[1]. Asking them to behave like a co-founder, except
without equity and any decisionmaking capability, is a bit much.

\--

[0] - I'm not saying "not important". Driving a garbage truck or managing
payroll data are examples of jobs that are boring, that don't "change the
world" by themselves, but are nonetheless very important - each instance of
such a job is a crucial thing for a segment of society that benefits from it
directly.

[1] - And in our industry, that does involve letting them run some of the
show. When you hire an expensive specialist, you do that because they have the
knowledge and experience you don't have (or don't have time to use yourself).

------
w_t_payne
The programmer in this story has realised this fundamental truth:

The spoken word is ephemeral and easily forgot. The design of the product that
pays the bills is not so easily undone.

What people say in meetings; all the posturing and preening; the petty one-
upmanship and power-play — none of this has any relevance to what actually
gets done in the real world.

When it comes to what actually gets implemented — all of the power is in the
hands of the programmer who gets there first. After all — once the die has
been cast and the direction set, who is going to undo the work and start
again?

In this, the programmer is the decider.

Programmers have an immense amount of power, and there is no reason whatsoever
why he shouldn’t simply ignore the pointless social preening and get on and
make the product that he wants to.

After all, the consequences of his decisions will ripple far and wide thorough
the product and beyond and have a heft; a level of consequence and a
permanence that no ‘soft’ skills specialist can match.

~~~
partycoder
A healthy team is a team with high social capital: a team that seeks the
common good, where people clean up after themselves and volunteer to help
others. Everyone wants the best idea to prevail. All this while preserving
critical thinking and trusting other people with the feedback that is
necessary to improve. Their most important competitor is another company.

An unhealthy team is a team with low social capital: a team that seeks
individual gain and people force others to pick up after their technical debt.
Everyone wants their own idea to prevail. All this while avoiding any form of
uneasy conversation and withholding feedback. Their most important competitor
is each other.

~~~
firepoet
Absolutely! And I've seen companies with reward structures that focus on
individual performance cause a lot of these unhealthy teams to arise
unwittingly.

------
m_fayer
After you have a good decade of experience under your belt, most programming
is... easy. Sure maybe not if you're working on self driving cars or game
engines or kernel modules, but then the programming is only half the point
anyway - the rest is math and science.

But if you're not working on one of those but doing something more typical,
and you're decently experienced and competent (and maybe also not compulsively
chasing the bleeding edge), then programming is often just cranking out
features, a steady drip of success. So of course the path of maximum pleasure
is to crank out code.

What's harder than coding? Smartly balancing the stakeholders. Maintaining the
discipline, motivation, and knowhow required to maintain the engineering
process - testing, documentation, CI, etc. Herding the cats that are a group
of programmers, managing the egos, ensuring that a team stays aligned on style
and architecture, that's the hard stuff.

~~~
pjmlp
The problem many programmers face, is that for the issues you mention soft
skills are a must have.

So of course, some find it easier just to code away without having to deal
with other humans.

Personally, I get bored to death on the projects where I happen to be a lone
dev.

~~~
humanrebar
> ...for the issues you mention soft skills are a must have...

Only because technical decision making is poorly structured in most
organizations. Or it's clear but evaluation of decisions and decision-makers
is poor.

If it were:

\- get feedback from these N<3 people \- here's how you do that \- they are
required to give clear decisions \- within X days

...it wouldn't matter so much that Engineer McCodeface wasn't the best at
attending happy hours, back-scratching, etc.

~~~
notyourday
This only works if your organization actually hired at a certain minimum level
of competency from EngineerMcCodeface[1..100]. In a hospital interns opinions
do not carry the weight of residents, residents opinions do not carry weight
of the attendings, and attending opinions do not carry weight of a Chief of
Surgery.

~~~
humanrebar
Also a good point.

------
partycoder
How would you feel if:

\- you were a chef. you went to culinary school and know about cooking and
best practices.

\- you are asked to forget everything you learned in school and flip burgers
with overly reused oil and unwashed equipment.

\- you are told that there's no time to clean the kitchen, or wash your hands.
just flip as many burgers as possible to maximize profit.

\- the ones that cook the most burgers are rewarded, treated well, promoted.
as soon as cooks realize this, they start making half-cooked burgers that make
people sick.

\- the customers get sick all the time from the lack of hygiene. you talk
about it, and you are told to keep doing what you are doing, or that you don't
understand what being a chef is, or what the business is.

\- in the end the only source of gratification is getting a paycheck, or doing
something in your spare time. you are not cooking real food, just part of a
machine that makes money for a self-serving company while ripping off the
customer.

This is what it feels to be an engineer in many companies.

~~~
mratzloff
You always have a choice.

~~~
pjmlp
Depends where on the globe one is living.

It isn't always easy to switch jobs.

------
crdoconnor
>But, two years later, Jamie was “that guy”. You know, the one who wants to
code without being bothered.

>I should have noticed the signs. He didn’t speak up in retrospectives, he
didn’t contribute process or product ideas like I expected, and his “team-
friendly” interactions were usually sarcastic. He often talked about technical
debt, our lack of innovation, and the “stupid” decisions holding us back.

I suspect if you just gave Jamie free reign to spend most (not all, just most)
of his time refactoring the code base and fixing up the dev tooling while
other people worked on bugs and features then Jamie would be happier, the code
base would be less buggy and the other developers would get their features
done quicker.

The fact that Jamie is quite grumpy about all of this suggests that the code
quality and tooling at this company is poor and he isn't being allowed to fix
the things that are causing him pain.

And maybe he doesn't want to meet customers? Is it so bad if that task is left
to somebody who _likes_ doing it?

>His enthusiasm for changing the world is replaced with nit-picking the
development process.

>Worse of all, though, his concern that “We aren’t building the right thing”
will be replaced with “We aren’t building the thing right.”

This attitude absolutely floors me. You absolutely want a diversity of
attitudes and skills on any team and that _includes_ having some people who
worry more about building the right thing and other people who worry more
about building the thing right. Those are complementary attitudes that usually
go with complementary skillsets.

~~~
alain_gilbert
You said something that reach me so much: "tooling".

I sometime feels like if you don't have good tools, it's almost impossible for
the employees to be productive or motivated.

I often see some people working in the most unproductive way possible (to my
eyes) that it actually discourage me. I'm left wondering how they can even get
anything done when spending so much time doing simple tasks.

~~~
crdoconnor
Yeah, I sometimes joke that the average developer is a somebody who pushes
their code with a series of repetitive git commands typed in unreliably,
deploys unreliably with a repetitive set of shell commands, relies almost
totally on a battery of bored, robotically clicking manual testers and
believes that he is automating people out of a job.

I think one of the most underrated (and almost totally ignored) parts of the
mythical man month was the notion of the toolsmith being a dedicated member of
a good software team _who doesn 't work on features_.

------
chrisco255
This is so on point:

"Culture isn’t the slogan on your wall, or how you describe your mission
during an interview. Culture is the way people actually act, and what they
actually care about."

PMs and Dev Managers, your engineers are smart, dynamic individuals. If you
engage them and include them in important conversations and actively solicit
their feedback while providing context and customer feedback, you will get
innovative and creative ideas, you will get an energized work force, and
everybody will be happier for it. Don't treat engineers like an assembly line:
software is a dynamic machine and it requires everyone's best work to evolve
in the right way.

~~~
PeachPlum
While you're not wrong about culture is action, here's studies show collecting
and disseminating that culture (aka writing it on the wall - knowledge
management in the literature) leads to measurable competitive advantage.

Sorry these are from journals

[https://www.scopus.com/record/display.uri?eid=2-s2.0-7795302...](https://www.scopus.com/record/display.uri?eid=2-s2.0-77953027877&doi=10.1016%2fj.jbusres.2009.06.005&origin=inward&txGid=00233ff082dcf44d5150557779b268f7)

[https://www.scopus.com/record/display.uri?eid=2-s2.0-8005505...](https://www.scopus.com/record/display.uri?eid=2-s2.0-80055059599&doi=10.1108%2f02580541111177548&origin=inward&txGid=d8b8914e2770bda839307aab61e242fd)

------
JeanMarcS
3 years ago I crossed the ocean to join a team on a project that seemed great.

I'm not 25 anymore so it was a big deal, moving my wife and kids (but it's on
a Caribbean island, so they were not hard to convince).

I was asked to join because of my background in mathematics, my vision on
resolving problems, and my programming skills.

Not bragging, I'm just a regular guy, but the person recruiting me was the co
founder of my company, we know each other for 25 years. So he knows me well
and know my skills. I was asked to join for bringing a new vision on some
tricky points.

Small team, one leader.

Almost every time I proposed something new, it was dismissed, and sometimes
with contempt.

Of course it's something they worked on for several years, and they tried a
lot of solutions before I joined, so some of my idea were surely already
tested and all.

But I ended up doing some UI on jquery (yeah, I know...) and became miserable
as time passed.

Because, you know, before even be sure that the core was working, they wanted
a fancy interface...

Ended bad. I finally quit after 18 months of doing the same stuff again and
again, as the UI changed every time a new idea came up.

My point is I totally understand the point of the article. I came with a bag
full of ideas and happiness on working on that. I ended doing shitty stuff and
feeling uninterested and bored about programming shit all day.

------
AllegedAlec
This hits a little too close to home for me.

I cannot count the number of times per that one of the following situations
has happened:

\- I go to our designers with an inconsistency, omission or even an outright
contradiction in the design just to hear that this is how it was designed and
that the client approved this design, so we should implement it precisely as
the design says.

\- Development is slowed down/held back by technical debt and odd
implementation choices. When I suggest we fix this, I get told that fixing
what isn't broken doesn't earn us money, so I should work around it for now.

\- I have a suggestion for some process improvement (for example: developer
post-mortems, including developers in the design review process), to get told
that it's already been tried at some point in the past (usually back in the
really early days of the company when there were less than 5 employees) and
that it didn't work back then, which means that it will never work, no matter
how much has changed since then.

~~~
rovek
> including developers in the design review process

I was banging this drum for 2 years at my previous employer. I was always told
it's a great idea but the people who knew projects were coming down the line
just never reached out to the tech team.

We are all tech consumers, letting the design team work exclusively with the
client is a great way to build the wrong product/features or
over/underestimate the art of the possible.

~~~
AllegedAlec
> letting the design team work exclusively with the client is a great way to
> build the wrong product/features or over/underestimate the art of the
> possible.

Pretty much this. We consistently get screwed over on our schedules because
designers just throw a design over our way without asking us for any input
along the way.

------
paulhilbert
"It’s only natural, then, that your programmer is reduced to doing only what
brings him success: coding."

Replacing "success" by "pleasure" quickly reveals why there's not a single
sentence in that article I can agree with. I for one am quite happy not being
included in matters that sound like a different job title to me...

~~~
ndh2
Oh, wow. Care to elaborate? I found the entire article so relatable that I
even thought about registering on Medium to be able to clap.

~~~
paulhilbert
I spent most of my day coding. Except for some fresh air breaks and occasional
discussions on how to collaborate I actually spend every second doing it. And
I love it. The article suggests in its whole premise that this is wrong. For
me and for the business. Yet it lacks any evidence on why I should want to do
more than that - in fact I would even call it blindly dogmatic in that regard.

But at least in my work context I think that my boss's job is to keep me from
customers and design decisions as much as possible - since that is what I love
and what yields the most productive use of my time. I wonder why my joiner
friends aren't told that spending all day in their workshop creating beautiful
wooden art is wrong and that they should instead derive more pleasure from
interactions with their customers...

Maybe in an ideal world someone who cries over every line of code since she/he
would much rather make design decisions but is left out of the creativity loop
just isn't a natural coder. Just like someone who hates working with wood
maybe shouldn't.

I am well aware that this is a position of extremes and blocks out the gray
areas that are reality. But _my_ work reality is just not what this "Hacker,
Problem Solver, Calvinist, Geek" regards as the very premise of his manager
lesson.

~~~
PeachPlum
Does it not bring you any pleasure for your users to find your work valuable ?

We could all just sit at home and write code all day. but without users there
is no point.

The situation describe in the OP is a result of a poor management culture,
which is why it's there.

~~~
Aaargh20318
> We could all just sit at home and write code all day. but without users
> there is no point.

Depends on how you are motivated. Speaking for myself, my motivation always
comes from myself, never from what others think of my work. The users/paying
customers aren't the point, at best they are an enabler, allowing me to spend
more time coding that I would otherwise have to waste by having a non-coding
job.

~~~
PeachPlum
I do totally understand that motivation, coding is enjoyable. I have lots of
code on github that I wrote that no-one has ever run since the time I checked
it in once it worked.

But the PHP code I wrote that was getting 1m pageviews a month gave more of a
sense of achievement than my clever raytracer.

------
qznc
I just realized that I turned into Jamie sometimes as well.

At the beginning of a project, I worked without respect to boundaries. When a
bug in another teams codebase held me back, I fixed it there. Over time I
learned that this was neither appreciated nor welcome for some, so I stopped
doing it. Unfortunately, this also a problem for me, because the bugs don't
get fixed and block me.

I invited a programmer from another team into my repo and we collaborated
there. Then I was told not to do the work for another team (by the other team,
ironically), so we forked. Now the repos have diverged and the users, who want
to use both, suffer.

------
reacweb
"He often talked about technical debt, our lack of innovation, and the
“stupid” decisions holding us back. An irritating “I told you so” sentiment
plagued his comments and feedback." I recognise myself very much in this
traits. When I work on a new project, I maintain a diary with a section todo
and a section technical debt. It appears, there are always many items in
technical debt.

The mindset of people is very influenced by their role. A developer is mainly
fixing bugs and creating architecture that should be less bug prone.
Anticipating problems is our job and does not mean we are negative. We are
happy when the technical debt is small. I think that this article shows that
people have difficulties to listen to developers and do not grasp their
mindset. I am quite happy my boss listen to me. In a previous job, I had a
colleague who helped me a lot to get listened to.

I think a developer needs to have good stretches of time undisturbed to get
work done, but needs to spend time discussing with others to understand their
needs and provide his insights. If nobody listen, the developer can only
complain like in this article.

~~~
JoeAltmaier
I agree. I imagine the beginning of the end is, the agile standup/sprint
process. Instead of addressing the code as a whole, we're reduced to picking
at one piece at a time in isolation. No development without a customer issue
to justify it! Especially the new guy.

And to come in after a couple of years of this, and find a code base that is a
pile of individual pieces in a loose spaghetti wad, is so absolutely
disillusioning. You want to fix it; you know what needs to be done; but you
have to add this field to this structure so some UI element can report some
crap that hardly anybody cares about instead.

~~~
sdiupIGPWEfh
Just realized this is now me. "A pile of individual pieces in a loose
spaghetti wad" exactly describes what I've been made responsible for. Each
source file shows scars of sprints where some poor fool was given a story and
told "just make it work" with no concern for any big picture.

~~~
JoeAltmaier
I'm so sorry! btw like the imagery 'shows scars of sprints' \- well said

------
downvote_me
There is a huge amount of insight on this post and I could not upvote this
story enough. It is exactly the onboarding process and all the BS/political
powerplay and non-productive rhetorics that pass that exact message to a
programmer. Multiply this by ten if you happen to be a non-native developer in
a mostly ethnic company where your language skills are below native. So -even
though it is never clearly said in the open- the message gets to be 'you are
just a "foreign" code monkey'.

------
thisisit
Wow. This article really resonated with me. I was "Jamie" until 2 months ago.

I choose my jobs very carefully. So when this company had a reputation of
hiring the best, I was beyond excited. The interview process was great. I
really liked interacting with the (future) manager.

And....things went downhill in the very first month. In the first team meeting
VP announced that the manager was moving on. All the while I could see it was
not mutual agreement between the manager and VP. But, I thought that was not
my problem.

A meeting was set with the new manager and there it dawned to me that I was in
huge trouble. The new guy wanted me to do a presentation in front of the VP
and other C-level executives. "But I am not aware of the project requirements"
I said. He summarily ignored my objections.

On landing in front of the VP and C-level people I was criticised for not
knowing the project requirements. While the old manager tried to help me, the
new guy kept his mouth shut.

Later the new manager offered me a half ass apology. That proved to be the
last straw and I became the person who just wanted to code.

------
Terr_
> Worse of all, though, his concern that “We aren’t building the right thing”
> will be replaced with “We aren’t building the thing right.”

Oh man, this one hits very close to home.

I can say there exists at least one additional circle of hell, found after the
engineer has abandoned all hope of influencing code-quality. The kind found
after executives have hired outsourced teams to "help" add features with no
code-review process or commit-hooks.

Perhaps: "We aren't logging errors right."

------
pipio21
As someone who has been programmer and now hires lots of programmers, there
are things in life you can't buy, like love, or in this case, respect.

I learned motorola assembler, then intel's when I was a kid and have been
programming all my life,studied engineering and made a software company from
scratch.

Programmers respect me in a way they do not respect an MBA, no matter the
title or the money they have. In a company it is a big problem.

You can't see it, it is invisible but man you could sense it, it is a very
strong force.

------
dgreensp
This article comes to entirely the wrong conclusion, and I am _very_
encouraged at the number of commenters pointing it out.

Engineers engineer. They are highly trained professionals who are doing their
job when they are figuring out how to build something, improve something, or
fix something, often with the goal of being able to develop new features
quickly without an inordinate number of bugs.

Your engineering team shouldn’t be running your business. Even if they have
good ideas. And in practice, they will be overruled immediately, anyway, the
moment someone with any real authority makes a roadmap or a key decision,
because they are engineers. They aren’t answerable to the board. They haven’t
studied the market and competitive landscape in depth. They can’t pivot the
company.

There’s something perverse and The Office-like about diagnosing Jamie as a
problem “but it’s not his fault.”

Engineer runs into boss’s office: “Sir, code quality is critically low. I
suggest we begin paying down technical debt before it’s too late.” Boss,
smiling to camera: “This is Jamie. When he started, he was a team player. He
believed in the vision. He didn’t spend all day nit-picking about things like
code quality. Look at him now! I don’t blame Jamie, though. I blame myself. If
I had made Jamie feel like his big ideas and product insights were welcome
here, early on, he wouldn’t have devolved into seeing himself as a mere code
monkey.”

------
petagonoral
Yet another person who I feel I would dislike working with. Maybe, at the
start of each post where people ramble in such a binary fashion, they could
post a snippet of why they think they can comment with authority on whatever
the article content is about.

This guys MO ties in nicely with most "well meaning" but utterly clueless folk
I've seen when it comes to software development.

Even more so when I see his site
([https://marcusblankenship.com](https://marcusblankenship.com)) has:

> Let me teach you how to create a high-performing software team

------
ju-st
I think managers begin to BS around and only caring about paychecks for
similar reasons. It's not only the lowest level in companies (programmers,
engineers...) who grow tired of non cooperating higher ups.

------
Jach
So there are two stages here... First is caring about the what, and getting no
traction in determining that. It's left to the PMs. Second is caring about the
how, trying to at least get ideas implemented on that front. But what's the
stage after that? If you get no traction on making a better what, nor doing it
with a better how?

Will a company with a strong why, a sense of purpose, that is felt and
understood by all the employees help ward off the troubles of obsessing over
what and how?

~~~
Terr_
> But what's the stage after that?

Unfortunately I feel like I can answer this (or at least suggest a direction)
from current personal experience.

When the engineers are not allowed to fix fundamental problems, the next stage
is about defending themselves from blame that they feel is not rightfully
theirs.

Ex: _________

"Hi Bob, this problem appears to be due to corrupt data. Our 9-year old
platform does not actually use foreign-keys or database transactions, and we
haven't been able to get approval to replace it."

"Alex, I haven't seen this feature before, it seems to be from the offshore
contractors and their PM. Reproducing the error, it seems they introduced it
about five months ago, so we'll have to check those records for mistakes."

"Mary, I'm afraid our software isn't able to support names in those languages.
I'm including a link to a memo I made three years ago that explains the
limitations and suggests some ways we could fix it, if the business considers
it a priority."

~~~
humanrebar
To be fair, not being able to attribute problems to their underlying cause is
a fundamental problem.

People strive for simple systems at least partly to seek property in their
system.

------
humanrebar
> Worse of all, though, his concern that “We aren’t building the right thing”
> will be replaced with “We aren’t building the thing right.”

To be fair, part of an engineer's job is to give her opinion on when you're
not building the right thing _because_ you're building the right thing in the
wrong way.

Building something with 10-100X more cost, unacceptable bug rates, or a pivot-
unfriendly design means losing money in many (most?) contexts.

~~~
JoeAltmaier
It can always be debugged in the next sprint! Just pick up another item from
the board and keep coding; if we get behind we'll just hire some more college
grads.

~~~
humanrebar
"Will this feature be profitable if it requires X more engineers per Y users?"

If the answer is yes, then I guess it's fine.

~~~
JoeAltmaier
Until the code base becomes so intractable, such a dinosaur of brittle
features and run-on code that nothing significant can be done without
exhaustive debugging. Then no group is large enough to make good progress.

Loose wads of code with random dependencies make the effort grow
geometrically. No growth in team membership can keep up with that for long.
The only solution is to tightly control dependencies, write good abstractions
and keep to them religiously, etc.

So many, many projects head off this particular cliff. They pretend to have
life for a while, reducing the feature set in each drop to smaller and smaller
items. Relabelling a bug fix a feature, and features overrun the
sprint/release and get relabeled 'bugs' so you can keep developing through the
test and release phases.

So many of us recognize the syndrome. But so little gets done about it,
especially in large companies.

~~~
humanrebar
> Until the code base becomes so intractable, such a dinosaur of brittle
> features and run-on code that nothing significant can be done without
> exhaustive debugging.

Yes. And that gets at the point of OP. "Let me replace subsystem A so we can
free up B resources per year" is a big, if it works. To throw it on the
backlog for "when we get time" is self destructive in the long run.

------
azangru
"Just want to code" as opposed to what? After reading the article, I am not
sure I understand what he wants programmers to do.

~~~
firepoet
I don't think the author wants programmers to "do" anything. Instead, they
want managers to allow programmers to bring their whole selves to their jobs.
That means not blockading their ideas from being implemented, regardless of
what realm they belong in. If a programmer has a product idea, they should
have a chance to prove it's a good one. If they have a process idea, it should
be considered. And so on...

------
lbill
TL;DR: I lived this situation on a shitty firm. It's depressing. But "good"
firms do exist, don't lose hope!

I lived this situation : I got hired as a developer and got involved into
making the product better and improving our processes. But the firm was (and
still is) utter shit. It was painful and I was unhappy.

Some people there are still trying to do a good job and they have had several
episodes of burn-out. Some other just lowered their standard and accept to get
paid to poop some ugly code and apply useless processes (some might be happy,
but most of them are dead inside). I just gave up on this nonsense and quit,
and was lucky enough to find a much better place. My new firm (not that "new",
it's been more than a year now) is not perfect and can definitely be
improved... But motivation and commitment into improving things are actually
welcome, and it works!

------
tetron
Some of these responses speak to the difference between "programming" and
"software engineering". If you want people to hack code without regard for
what it is for, you get programmers. If you want a team that is fully engaged
in building a product (which means the whole life cycle from requirements to
deployment) you need software engineers. If you disempower developers from
that kind of decision making, it doesn't matter what their title is.

------
dazzer
Hah this is pretty much me at my current joint... and the worst part is it
just feels like there's nothing left after.

------
aviso5
Programmers can't into graphic design -
[https://youtu.be/NM1UeFFCofY](https://youtu.be/NM1UeFFCofY)

~~~
prsy
This is spam

------
megaman22
It's not just programming; anything where your thoughts and concerns are
automatically dismissed and shoved aside becomes incredibly demoralizing.
Eventually you either give up completely, or you settle into the tiny corner
where you're allowed to have opinions and act on them.

