
Why ‘your’ programmers just want to code - rbanffy
https://hackernoon.com/why-your-programmers-just-want-to-code-36da9973388e
======
overgard
I think there's a bit of learned helplessness, but I also think that a lot of
this is _because_ of agile (or more specifically, scrum), not in spite of it.

The amount of micro-management that goes into most programmers day to day work
makes it extremely hard to be innovative, because you essentially have to
justify what you're working on daily -- and any creative person knows that not
every idea pans out. You need managerial support to occasionally make
mistakes.

There have been a lot of times in other jobs where we'd have a slack in our
schedule and I used the down time to make a change that was really necessary
and took a minimal amount of time, mentioned it in a standup meeting, and got
blasted for not working on our "commitments" for the "sprint" (even when I had
nothing to do).

Companies always talk about wanting ideas from workers and how important
innovation is, but they're not willing to extend the trust to their people to
create an environment where that can happen. People naturally become
disengaged when they're not trusted or valued.

The worst part is that it's not just management creating this mentality, it's
the other programmers. I've noticed that younger more inexperienced
programmers tend to crave the structure of agile, whereas the older more
experienced programmers chafe at it. I think if programming had more of a
culture of apprenticeship and mentorship, and a deeper appreciation that this
is hard and it takes a long time to get good at it, our industry would be a
lot healthier.

~~~
vvanders
That sounds like poorly run scrum more than anything else. I can't count the
number of times I've thrown an "investigation" task on the backlog that may or
may not have panned out.

Scrum is more about keeping your fellow engineers informed on what they are
working on so incompatible things rise quickly. It shouldn't be used as a tool
for micro management but instead reviewed at the end of each sprint.

~~~
zukzuk
And this is exactly why "agile" has become a religion more than anything — if
it's not working, it's because you're doing it wrong. You just need to agile
harder.

~~~
Bahamut
To be fair, it really does sound like bad management - management shouldn’t be
blasting an individual during scrum. Management also shouldn’t care if other
work gets done as long as the core commitments get finished. Good management
shouldn’t hamstring you like that - engineering doesn’t work like that.

That is regardless of agile or whatever development methodology you use.

~~~
TheCoelacanth
Management really shouldn't even be participating in any of the scrum meetings
other than the sprint review. All of the other meetings are supposed to be
just for the team itself.

------
jmartrican
As a veteran in this field, I find myself not trying to ask permission as much
for new ideas that I can do on my own. Multiple times in the past I have done
my own ideas,while getting feedback from peers and those that are affected,
but generally leaving management out of it and not seeking permission. Some
ideas panned out, some did not. But I had a great time, got satisfaction from
my work, grew and learned. Then other times I would get into this mode where I
want to get permission and let managers in on what I am doing. At first it
starts out OK. You scale back your ideas due to their concerns. Then you get
redirected... "maybe later but now i want you do focus on this". Eventually it
leads to a new job. I think this article helped me pinpoint this pattern, even
though I suspected it.

It is a balancing act. You do not want to waste company time with oddball
ideas, and some of your ideas will be oddball. You need to seek feedback on
them so that they can be improved. You need freedom to try them out, and fail.
I think this article is good for both managers and developers. Developers
should know that this pattern is real, and there are things you can do to
protect yourself from going down this path. For me, its basically not always
asking for permission to try stuff out... take a risk and believe in yourself,
but also get feedback to filter out oddball ideas that waste time.

~~~
stuaxo
Definitely second this. Taking risks like this is the only way I've kept the
job interesting, and managed to make the projects actually good.

The downside is when it doesn't pan out, you can have a bit of catching up to
do.

~~~
jmartrican
> The downside is when it doesn't pan out, you can have a bit of catching up
> to do.

That is so true as I am catching up now on a Saturday. You also learn to not
roll your own solutions and check a second or third time for a solution on
Github or open source community.... and check again if you don't find it.

------
seattle_spring
Wow, this article echoes exactly why I'm leaving my company next week. Was
hired 2 years ago as architect, but over time ended up just being micromanaged
by upper management. Got bitter, cared a lot more about pay than I used to,
and ultimately put my notice in.

~~~
nimbius
this is absolutely my sentiment. I started 3 years ago as a senior sysadmin. 2
years later its clear directors call all the shots, management tells engineers
to do it, and we're expected to cheer and support the result if its moderate
success is achieved, or ignore the fallout if it fails spectacularly. most of
my meetings have turned into head-nodding and shrugs.

Lifers at the company dont care about new ideas, and any effort to change is
met with cynicism and vitriol.

~~~
itomato
Do you understand the cynicism? Is the vitriol real or imagined?

If you have ideas that are both "complete" and relevant to the business,
you're right to be ticked.

If you're just spitballing about "things that could be better" without
concrete information about what quantifies "better", you're probably not being
taken seriously.

~~~
Retra
Ideas can't become complete if you're not allowed to work on them. Nobody
pitches complete ideas unless they're doing something that's already been done
hundreds of times before.

------
ergothus
I think the article is overly broad, or at least poorly titled. I've wanted to
"just code" in two scenarios:

1 - as the article describes, I've been shown an environment that is hostile
or apathetic to any of my ideas.

2\. When I am with a team I trust to make well-considered, well-timed,
well.communicared decisions. Sure, I participate more when in planned or
unplanned meetings and my interest level/enthusiasm is high, but my main
value-add is to code. If others are great at their jobs I'm free to try to be
great at mine. Coders are problem solvers. If the biggest "problems" are my
code, then that is where I will focus.

It is worth noting that we've chosen a career about programming, most of us
because we enjoy it. At the start of our careers we are constantly learning,
feeling accomplished, and have a amount of time to focus on coding. Over time
we start contributing in less direct ways - planning features, scheduling,
mentoring. The projects get bigger and more complex. We learn the "easy" parts
of the craft and start wrestling with the harder, more subtle, and more long-
term aspects.

All good stuff that enables more pushing of that Skinner button (coding)...but
we get that sense of accomplishment less and less often even as the stakes
involved increase. So we yearn for the earlier days and try to recapture that
feeling.

We use and write tools that allow for ever-increasing efficiencies. Humans in
meetings? Relatively nothing has improved in decades...it is easy to have that
feel like time in a meeting is a waste.

We are solution discovering junkies - don't be surprised when we try and find
the high.

------
scarface74
So, my job is officially "dev lead" but I'm really just a glorified senior
developer who the company (use to) listen to more than other people until they
brought in a "scrum master" and started going "agile".

I had one process that I designed that wasn't reliable. I didn't realize it
until the volume started going up. The people in the field were complaining
about the process not working reliably, somehow that got translated to senior
management as "performance issues", by the time it got back to the "scrum
master" and my immediate managers, I was being criticized about working on
"the wrong thing" because I was focusing on health checks, auto recovery,
scalabiliy, high availability, and most importantly improved logging to
determine what the issues were instead of making it faster - ie improving the
speed (performance).

After much arguing, I was able to prioritize one improvement that would
improve reliability when processing large data sets and I was able to
prioritize logging of both successes, failures and time it took to run
queries.

I was not able to prioritize connection resiilliancy even though I knew that
was part of the issue.

So we had a big outage while we were working on the "performance issues"
caused by spotty network connections that could be improved if we implemented
retry logic (that got deprioritized). But we couldn't add the resiliency
because it wasn't going to make things faster and it wasn't part of the
sprint. What was even worse was that part of the exception message from Entity
Framework said that the error was "transient" and that we need to Implement a
resiliency policy.

Another part of the issue was based on an unoptimuzed set of queries that were
causing reliability issues and that was prioritized. But while implementing
that, I realized that there were other performance bottlenecks caused by API
calls of semi static data that could be cached. I did a simple in memory cache
and was lambasted about that since it "wasn't part of the story".

At that point, when you can't change your environment is time to change your
environment. But in the meantime, it's a matter of communicating to senior
management the decisions that were made by the scrum master and my manager.

On the other hand, I always keep my resume updated, my network fresh, and my
skill set in line with the market....

------
falcolas
After 6 months spent on "investigations" into technologies with no tangible
outputs aside from a 1 page summary of those investigations, I'm nearly to
this point. I just got really salty when our department clarified what
positions were available for advancement, and I realized I've been doing those
jobs for years with no signs of pay raises or titles.

What bothers me more today is that a title, a pay bracket, bothered me; that I
am annoyed that I need to come up with a promotion packet. These, to me, are
signs that this is just becoming a job. For all of my constant assertions
about business relationships and other such comments, I was still holding out
hope that it would be more.

So, yeah. Empower your developers. You're paying them a lot of money; make use
of and recognize the value of that talent you're buying.

~~~
stuaxo
Best way of getting a decent payrise is to find somewhere else work.

~~~
falcolas
Indeed. But I'm reaching a point where I'd rather find a single employer that
I can work with for more than two years. It's... harder than expected.

~~~
scarface74
Why? I've changed jobs 4 times in the last 9 years and make 65K more than I
did then. On the other hand, I stayed at one job 9 years - seven years too
long - and between bonuses being cut and small raises, I only made $7K more in
year 9 than I made in year 2 and found my skills outdated.

I vowed I would never make that mistake again.

~~~
falcolas
Another $15k or $20k isn't going to change my life. Having things I want to
work on will. In my ideal world, I would have work I want to do and wouldn't
care if my salary did anything more than keep up with inflation. I wouldn't
have to keep my whiteboarding skills sharp, wouldn't have to keep learning how
new company Z's politics are just as silly as company X and Y's.

The fact that the money and titles are bothering me is the sign that the work
isn't something I want to do.

~~~
scarface74
There are three reasons for me to leave a company - technology, environment,
and money - in that order. Since I started on my mission in 2009 and left a
company I had been at for 9 years, every job change was about all three.

Now, I don't see my next job change as being about money. It's more about
using the latest technology that will keep me relevant. But if a company is
not willing to pay you market rates, it does tell you something about the
company.

But as I've moved up in my career, I've found that the only way to implement
the technologies you care about is to both keep your presentation skills sharp
and know how to play politics.

------
weeksie
You know the other side of this? Sometimes those bright ideas are 1) not very
bright at all or 2) bright but utterly wrong for the current context. A mature
or maturing developer will learn to adjust their input to match the context.
An immature developer will sulk and want to "just code" and blame everybody
else around them for not encouraging their creativity or whatever.

That's the tough thing about articles like this. It's an article that is 100%
correct, assuming that the developer in question is both talented and on the
cusp of enough maturity to grow in response to gentle redirection rather than
bristle at it. Problem is, that's a narrow band on the immature/mature
spectrum. A more mature developer would address their concerns, a less mature
developer will bristle at everything anyway.

~~~
NPMaxwell
Problem is, as far as the coder is aware, the ideas are dismissed before the
manager knows that the ideas were. Maybe bright; maybe not. Usually no
explanation is made for why the ideas were dismissed. If an explanation is
made, the coder isn't being disrespected and doesn't go down this path.

~~~
weeksie
In a perfect world, sure! The thesis of the article was that the _reason_
developers only want to code is because they aren't being given explanations.
While that might be the case sometimes, it's nothing near a hard and fast
rule. In fact, sulky behavior is often an indicator of immaturity even if the
management also sucks.

------
jordanpg
I thought this was going to go in quite a different direction.

In addition to culture, programmers might want to just code because their time
is so consumed by meetings, support, and chat, that they hardly have the
chance during normal work hours to code at all.

------
jxm262
This hits home for me pretty hard. Honestly reading it felt kinda therapeutic
as I still occasionally have bad dreams from a previous company (ideas being
shot down, trying to fit into an existing team, etc..).

especially this comment -

> Existing teams have established relationships, and are easy to offend
> collectively

[https://medium.com/@prajjwalsin/this-sort-of-thing-can-
even-...](https://medium.com/@prajjwalsin/this-sort-of-thing-can-even-stem-
from-social-discord-and-it-might-not-even-make-it-to-the-manager-e513337bfeaf)

Fwiw, there are companies/teams who act quite the opposite of this article
(encourage ideas..). I've been part of many of them and it's something I try
to look for now.

~~~
andai
It just occurred to me that, for people high in trait Openness (creativity,
appreciation for ideas) it might be a good idea to figure out ASAP (eg, during
initial interview) if the company is really open to new ideas or if they just
they are.

~~~
jxm262
Agreed. I try to ask kind of open questions during the interview process - I
see you're doing this task with 'x' technology, have you considered using 'y'?
Sometimes you'll get good responses back along the lines of why they picked
the tools, but express an openness to make different choices if you can help
them figure it out.

Honestly I'd love to hear ways to actually interview the interviewers on
things like this. I feel most of the material I read talks about how to
interview candidates, but there's not much about the other way around (how to
assess the company you're interviewing with?)

------
NPMaxwell
Summary: Blankenship is saying coders get really hard to manage because their
managers dismiss the coders' contributions to deciding WHAT to do. Blankenship
says the coders then retreat to safety: HOW to do things is safety for a
coder, because of the coder's greater expertise in the area of HOW. But with
this type of manager, HOW is often ignored as well. That's why the coders get
frantic, or worse, the coders stop commenting on HOW, and start working to
rule ([https://en.wikipedia.org/wiki/Work-to-
rule](https://en.wikipedia.org/wiki/Work-to-rule)). Pretty quickly, the coders
have forgotten any attempts at contributing to WHAT to do. In a follow up,
Blankenship says a solution is "Be humble. Listen more. Ask more than tell."
([https://hackernoon.com/a-wake-up-call-for-tech-
managers-d041...](https://hackernoon.com/a-wake-up-call-for-tech-
managers-d0415775efd0)) and he says the 1-on-1 is the place to start. That's
where you want to end up, but I'm skeptical that advice is going to do the
trick. Sometimes you need to tell people to do B so they end up doing A. For
example, it's not a great strategy to try to make yourself happy by choosing
to be happy; instead choose to be grateful
([https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3010965/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3010965/)).
I think this may work better: 1) "Try not to appear insane (and stupid) to the
people you supervise", 2) "Make sure your reports understand what you're
thinking and doing enough so they could replace you and accurately speak for
you in any meeting", and 3) "Don't waste the intelligence of your reports:
capitalize on their insights and perspectives." That has worked in my own
managing (says the man who just got "laid off" :) ), but I haven't yet tried
it out on other people.

------
patientplatypus
I kind of get what the author is saying but he sort of reaches a strange
conclusion. Programmers just want to be left alone to code more often than not
because being stuck in meetings all day or "interfacing" with management and
sales is actively harmful to our careers. In any given day I can have 3 to 4
hours of meetings that are handholding sales guys who can't be bothered
reading a medium article on the technology they're selling customers. There
are more than one programmer in my division that's turned apocryphal because
they never have time to practice their art. If the author of this article
thinks _more_ inclusion in business decisions is what I want he simply doesn't
get it.

~~~
rhapsodic
_> here are more than one programmer in my division that's turned apocryphal
because they never have time to practice their art. _

What do you mean when you say they "turned apocryphal"? I've never seen the
term apocryphal used like that before.

~~~
patientplatypus
They can talk about code at a deep level but if they try and sit down to write
anything they can't. Essentially sales meetings turn programmers into just
more sales people. It's incredibly sad.

~~~
JustSomeNobody
Almost at that point now myself. I have a deep understanding of our business
and I have no problems designing new solutions to business needs but lately
when I open up the IDE it's like staring at a white piece of paper and I
think, "ok now what?" I just don't have enough coding time to stay in
practice. Once I do get some time to get going it starts to flow, so I'm not
_that_ far gone yet. Really, I think I just need to move on but I love the
industry I'm in so it's hard to make that decision.

------
mythrwy
Programmers just want to code because the focus required means proper coding
is all you can do. Not answer phones, not be bothered every 10 minutes, not be
interrupted for group circle jerk meetings so "social" leadership can look
like they are contributing to the world rather than leeching off the work of
others.

But that's not what the article was about really. It was more about guy who
sounds like he is sick of foolishness and ignorance but hasn't turned in his
notice yet. Or else yet another burnt out cynical person who spent too much
time heads down in code.

------
oblib
I have no problem with offering ideas and suggestions when discussing how to
build software, but honestly, I don't care if management decides to go a
different route.

I'll code what they want the way they want it the best I can. That's the job.
This approach can lead to some "I told you so" moments when I've been ignored
and I deal with those when we run into them.

Over the years I've seen a lot of my coworkers get overly upset in these kinds
of scenarios and have endured way too much time listening to them complain
about it.

The thing is, there's almost always more than one way to do something. If it's
my job to choose the route I'll do that and lead the way, and if it's not I'll
follow the route chosen but I don't see any reason to get hurt or frustrated
by it because I'm getting paid the same to work on it no matter which route is
taken.

That said, there have been a few times when my route wasn't chosen and we got
stuck right where I said we'd get stuck and in those cases the project either
collapsed or we went back and started over using the tools and methods I
suggested. Doing that "feels good" but it pays the same.

------
abraae
tldr; programmers are creatives, so don't treat them as just resources.

~~~
krapp
Realistically, though, programmers are just resources, as are creatives, as
are their managers, as is every other employee. That's the way nearly every
business works.

To expect otherwise from one's relationship with an employer, particularly in
an at-will employment environment, can be dangerously self-destructive.

~~~
coding123
I think I'd say the same if I worked for my first employer for the rest of my
life. At this current company I enjoy hugs from the CEO. If you treat all the
interactions in life like family and with respect you might find the world can
change.

~~~
hobs
You might have a great place, but I would generally avoid any company with the
"family" talk - it's a very common tactic to generate additional loyalty for
no monetary investment, and you later find you might be in an abusive family.

------
draw_down
I appreciate that this author is trying to get management/leadership to own up
to their responsibility for a real problem. Yet I wonder what this person
thinks programmers' proper role is in the organization. (Let me also point out
that they chose the word "programmers")

It's a good insight that when people only have their ideas shot down, they
turn away from that and focus on other things. But I don't appreciate that
caring about money is (as usual) cast in a negative light, meanwhile the whole
point of a modern business is to turn a profit and make the shareholders
money. To the author's point, if the programmer is passionate about market
share, and suggests something that leads to market share growth, will they
benefit materially from that? If not, isn't that also a reason they would
disengage? But see, then we have to talk about _paying people_ instead of just
being nice to them when they offer up ideas. That’s a whole different
ballgame.

I'm not comfortable with how much this seems to imply that leadership
shouldn't try to, you know, _lead_ with the vision for the future and all that
nice stuff. Input should be welcomed of course, but at some level, leadership
_should_ be thinking and communicating about what should be built, and how the
world is going to be changed by your "Uber for sandwiches" app. This is why
the leadership will take all the money if/when the business is a success.

And your programmers _should_ care deeply about how the thing gets built.
Because, just for one thing, if it gets built wrong, that's going to become a
big problem for them.

\--

Some other thoughts:

The author talks about how if your non-technical ideas get shot down, you
won't bother anymore. It can also go the other way- I've definitely been in
situations where my technical ideas got shot down enough that I didn't try to
offer anything further.

Many companies (tech and otherwise) are ultimately a set of cliques- if you're
in with the right groups, you and your ideas matter. It's not set in stone;
the membership of these groups change over time. But you have to fight and
strive for a place within them. That is also a reason people disengage: it’s
not worth it, and getting there sucks.

It's definitely not good if a team member's interactions are often sarcastic,
however, the author's response to the "I told you so" attitude is telling.
Usually when people don't like hearing "I told you so" it's because they were
in the wrong but don't want to admit it. They'd prefer to move on without
doing any thinking or discussion about why the wrong decision was made, and
how the team could avoid that in the future. To be clear, it is rude and
unhelpful to cop an "I told you so" attitude. But it is also unhelpful and
dismissive to label that attitude a problem without digging any further.

