Why ‘your’ programmers just want to code | Hacker News Reader

Why ‘your’ programmers just want to code

hackernoon.com

137 pointsrbanffy105 comments

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.

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.

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.

Well, there are no absolutes in this industry, if there were then we all wouldn't have a job since it would just be paint by numbers.

If a process isn't getting you what you want then change it. Is it any wonder that repeating a broken process gets you broken results each time?

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.

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.

I've never seen agile work with sprints. Things change too fast and usually there are unknowns. I have seen Kanban work because it takes into account the reality that priorities change, and estimates are never accurate.

I am also a big believer in hard short deadlines when it comes to doing releases. When the deadline comes, release what you have ready and put it behind a feature toggle if needed to do a phased rollout.

If it's not working, why isn't it addressed in the retrospective? If you have a proper retrospective, you can change anything, even going from scrum to kanban.

This is 100% true. Who is holding you back to address things if they aren't working? I've literally never in my professional life have encountered a situation where honest feedback wasn't appreciated.

If you encounter situations where you are being micromanaged, try to place yourself in the role of the one who is micromanaging and try to see his challenges. That person is just somebody who is trying do his best. No one wants to suck the joy and energy out of his or her colleagues.

There is very little you have to add to "keeping everyone informed of what you are doing" to end up at micromanagement.

Notice I said engineers and not management or everyone, very small but important difference.

The thing is though, the number of times I've seen engineers work on conflicting/redundant things without realizing it (outside of the agile/scrum environment) has been vanishingly small. And the places I've seen it it's always been on separate teams that would never have been part of the same scrum group in the first place (ie, it was an inter-team problem rather than an intra-team problem)

This rings true for me. At one of my former employers our scrum masters came up with this idea of a ‘scrum-of-scrums’ where team leads would get together once every month and have a standup to talk about things they’re working on that could affect other teams. But it became a painful waste of time because some of the participants didn’t understand that we didn’t want to hear them talk about every single task their team worked on. Then we tried ‘release-train’ planning where the whole company would do 2 day company-stand ups. That was even worse. The real problem was that the company had a weird cultural and engineering mismatch between hardware and software engineers and the upper management was too clueless and careless to coordinate between them.

> You're doing it wrong.

This is the nonfalsifiability of a religion surfacing.

THIS is the problem. This very thing.

The implement is ALWAYS blamed.

The problem with "investigation" tasks or "spikes" is that it still boils down to essentially having to ask permission to do something. I really think extreme one-sided work transparency and a culture where everything is measured and permission has to be sought to work on something is entirely antithetical to encouraging creativity. Innovation tends to come from playfulness, and having to schedule a Jira task with a project manager for every idea is going to have a chilling effect.

You’ve hit my first main point of hatred against agile. It’s really a form of micromanaging in disguise. They sell it as developer empowerment but that’s just cognitive dissonance.

That depends on the company. Some companies (in my experience) do engineer-only scrums where programmers can talk about their blockers and ask for advice from seniors; others do mixed scrums where the engineers are basically reporting their progress to the product manager or someone, and where often technical questions are discouraged.

I'd tend to think the latter are "doing it wrong", but then again, who am I to say? I just know I much preferred working for the companies who did it the former way.

This idea that only managers micromanage and fellow engineers never do that us one of biggest agile fallacies.

Also, need to ask question should not require whole team meeting.

This is not a problem of agile, it's a problem with the implementation of agile. A company that tends to micromanage that implements agile will use agile to micromanage. It's unavoidable.

I've heard various forms of this response before but I'm always confused by it. If agile isn't the offending processes in question then what is agile.

And if the response is it's a verb not not a noun then it's really nothing but good hackers employing tried and true practices.

Anytime someone complains about agile and then a "true believer" defends it as "that's not agile", it reminds me of the "No True Scotsman"

Quite. I’m sure I’ve seen “no true scrummaster” used in the past to describe this form of debate.

I can't imagine taking up an investigation of any significant size (say, more than a day) that I don't mention to my team. And yes that means putting it on a board. This isn't asking for permission. It's making others aware. There's a good chance someone on my team has some valuable input. Or awareness of what time doing may affect what they choose to do somehow.

Granted, my team is small and close-knit. But the idea that keeping others informed of what you're doing is considered "asking permission" points to some serious pathology on your team.

And that pathology is not agile or scrum. We do scrum, and I'm sort of lukewarm about how much I like scrum. But whether we're doing scrum or something else, I am completely empowered to make my own decisions about my work. And I simultaneously value that the rest of my team keeps me informed of what they're doing. This is how we kick ass.

Nothing in agile stops you from creating experimentation tasks or simply spending time on whatever you want. It just asks you to honestly be aware of how you spend time.

Well, I'm pretty well aware of how I spend my time. Agile serves no purpose for me in that regard. The point of agile is so that others can track how I spend my time. Whether that's reasonable and if/when that's a good idea is entirely about context; but much like quantum mechanics, observing behavior can change it (positively or negatively).

When I've done R&D in an agile setting, usually the research was done outside of the scrum process, and once that was done then the development would be done in a standard scrum methodology.

The reason you can't really apply "Agile" to research is that having a useful product at the end of each sprint is a central to Agile development but runs contrary to the purpose of research.

Now, you still need to manage your research process. You need to identify the specific research questions you need to answer, and you need to bound the time investment. But let's not try too hard to shoehorn a methodology primarily oriented towards IT consulting into every other domain.

How many points did you give those tasks? We're the points agreed upon by the team? Did the team and the business agree to the tasks being included in the Sprint during Sprint planning?

It sounds like you created the tasks yourself and added them to the backlog mid-sprint. If that's what you did I'd be totally cool with it but I can tell you a lot of "agile shops" would blow a gasket over that.

Having been on a lot of teams with various processes, it seems to ultimately come down to trust. I’ve seen teams where there’s a ton of trust and mutual respect, where even a very structured agile approach has allowed for sprints focused entirely on innovation and exploration. Process is just another tool; how it’s used — and the environment — matters a lot.

I think the flip side of this is that Agile does not add much in the best case (people trust each other), but it can cause a lot of damage in the worst case (nobody trusts each other, but people can be productive thanks to a lack of transparency).

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

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

Yes! You're right that companies say they want ideas and then dismiss them, and that this is something co-workers often do to each other. I doubt this is a scrum/not-scrum issue. I think a manager (or master) can be dismissive within almost any work organization structure. The example you give looks like someone a) feeling entitled to blast you (What gave them that idea!?! I'm not an agile expert, but I'm sure "Chew people out" is not a part agile.) b) They blasted before understanding your thinking and decision making, thereby appearing to be stupid to you and to all us Hacker News readers years later.

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

That doesn't really have anything to do with agile or scrum though. Just add a refactor/investigation task to the backlog for the sprint. Those types of activities should be justifiable too. If your team doesn't allow those types of tasks for some reason, that's more of a team problem than a problem with agile.

"Justifiable" is the key word though. Why do I need to justify what I'm working on daily unless I'm not trusted? I mean, like most programmers, I have a four year computer science degree that was definitely not easy to obtain, I have like 10 years of experience, I've shown an understanding for prioritizing things that actually are important for the business, and they pay me a six figure salary for my expertise, so having to justify myself daily seems, frankly, insulting. I've worked in places where I didn't have to do that, and you know what? The sky didn't fall. Work still got done. (I would argue, more work, because people were more engaged since they felt a sense of ownership). We just had extra time in the day from fewer useless meetings, and a lot less politics from people trying to game the numbers they pull out of Jira and stuff like that.

This is a toxic attitude. Your 10 years of experience and 4 year education don't make you infallible. A high functioning team works closely, and that involves everyone's decisions being subject to scrutiny. If you can't justify your work, then it probably shouldn't get done. If you won't justify your work, then you don't deserve the six figures.

I never claimed to be infallible, and I'm happy to explain what I'm doing if someone asks, but ask yourself, how many other skilled highly educated professions are asked to provide such a humiliating measure of unnecessary transparency? (Hint: not most of them). Does your manager give you such transparency into what they're doing day to day? (Generally speaking: nope!) How do I know they're not just spending their afternoon's playing golf? (I don't: but I wouldn't work for them if I didn't think they were mature capable professionals).

Think of it this way, in relationships, business or otherwise, what's sub-communicated is just as important as what's explicitly communicated. Often it's more important. And what's communicated via most agile processes is that programmers are unimportant cogs with no business knowledge that can't be trusted to not stray from important tasks. I think that's ugly.

When a lawyer or consultant bills a client he has to enumerate how each hour is spent. As an engineer in another field I submitted all my calculations for peer review, and all my drawings had to be signed by a manager.

When you buy a grocery product you get a list of every ingredient and all the nutritional info.

It's nothing more than transparency and accountability. The one paying the money wants and deserves to know what it's for.

Your example is much closer to a code or design review than a daily scrum meeting. I don't think he's against design meetings or reviews.

Also, software development is quite a bit different than other engineering disciplines, at least at the application development level.

This made me think of the book "checklist manifesto" which argues that surgeons should be forced to follow a checklist to make sure they don't miss anything.

Part of the argument is that often the more junior members of them team know the surgeons are making mistakes, but there's no way for them to point this out without being bullied. Anectodes include the wrong leg being cut off while members of the medical team know it's the wrong one, but darent risk their career to mention it.

I'm not sure how this relates to your comment, except your line about other professions reminded me.

I would think the equivalent of that kind of thing in the software world would be things like automated testing and code reviews. (IE, processes that recognize people are fallible and provides mitigation). I think scrum is a different beast from those kinds of things (especially given that there's very little evidence for scrum's supposed effectiveness)

The problem is in your team or your corporate culture. Not agile or scrum as a whole.

On my team, agile is a process used among peers to coordinate. No one is a cog. No one is checking up on anyone. We keep each other aware of what's going on because you have to in order to coordinate and collaborate. My manager is just one voice among many on the team. He isn't tasked with monitoring my work because I don't need a babysitter.

I'm sorry that you work somewhere where you feel someone's monitoring or checking up on you. Where I work that kind of situation is called a Performance Improvement Plan. If you're not in that situation and are a highly productive individual, then your culture is broken and you should look for a different job.

But you're wrong that agile and scrum are at fault. If you used any other process, you'd have the same problem.

Well this is an aggregate opinion based on the last three places I've worked, mixed with a lot of conversations with peers at other places. It's certainly possible that I've just been unlucky and my colleagues have also been unlucky, but I would also point out that I've seen pretty much zero in the way of objective proof that agile actually improves anything, and a lot of subjective experience that agile doesn't actually benefit engineers. Frankly, I think it's up to the agile proponents to objectively demonstrate why this is better -- but 99% what I see is vague promises mixed with attempts at shaming people for "doing it wrong" when people say it doesn't work. (Not to mention the whole "waterfall" boogie man. As far as I can tell in the agilista world-view if you're not doing agile, you're 1970s IBM and you wear a blue suit to work every day)

Anecdotally, the last place I worked, I was on a small team that didn't really do agile. This was composed of some of the most competent, extremely smart people I've ever worked with that had decades of experience in the CAD field and had worked together for a very long time. We're talking people with like dual PhDs from very respected universities that have been working in the field for like 20 years; kept very sharp by going to C++ conferences, were very particular about testing and code reviews, and so on. I remember the corporate office tried to impose agile on these people, and after humoring it for about a month the whole thing was mercifully abandoned because everyone felt like it was ridiculous and it was slowing things down and causing a bunch of friction when some ridiculous consultant wanted us to do "planning poker". The only people that really wanted it in the first place were essentially remote project managers that were annoyed with these uppity engineers that thought they knew better (which frankly: they did; 20 years writing CAD software and you're going to learn a thing or two, whereas the project managers were pretty much just dabblers -- and when they couldn't convince people to do what they wanted by merits of their argument, they just wanted to install "process" to essentially strong-arm people into doing their will)

Yikes... this is a toxic attitude. I'd expect that kind of scrutiny in a hard-hat and lunch pail assembly line job, not a purportedly professional career.

Professional doctors, lawyers , and plumbers are all accountable for their time.

Being a professional means having the self confidence and emotional maturity to justify one's work whenever it is called into question. In fact, one should do the due diligence (including cost benefit analysis) to be able to answer the question with ease.

If you can't answer "why are you working on this?" easily then you're not doing your job. And if you resent being asked the question, then you either are self employed or you forgot who pays your salary.

You may be saying the same things. It seems like the person you’re replying to emphasized _daily_ justification of work, which does seem unnecessary to me.

Being open to having to justify anything that's called into question, and being capable of doing so, and being happy to... are different from forced to.

I sort of agree with you. A lot of "justification" ends up being such a frustrating waste if time. Usually necessary though.

Yeah, not once have I been involved with a project or team attempting some forced process where an objective benefit to cost analysis was done on the process itself.

This is spot on. It's the Enterprise's Holy Grail; the attempt to commoditize software development.

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.

As a (relatively) young less developer, I love it if my team members put on their own initiative – as long as it doesn't affect the deadlines dramatically. Sometimes developers want to implement the feature they're working on in the best possible way, while what there project really needs instead is ten different features, implemented just well enough.

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.

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

I'm doing that too and I'm always extending my estimation of work to include those potential researches. Smart people said, estimate work to be done and multiply it to Pi. If I'm feeling uncertain, I'm additionally multiplying it to E. Result estimation might be a bit pessimistic, but I've found that it's better than wrong estimate resulting in missed deadlines and work at nights.

(throwaway because I don't want to identify the company)

That works for some things, but not the others. For instance, right now I can almost mathematically prove that we're building the wrong thing, starting from 2 very "common sense" and reasonably easy-to-believe "axioms". I have no trouble convincing fellow engineers that we're not building the right thing, but that's more harmful than useful. I've managed to convince some director-level people, but trying to bring this up to VP-level yielded clear warning signs that not only will I achieve nothing, but it's going to be a career limiting move. The Upton Sinclair quote is quite true - "It is difficult to get a man to understand something, when his salary depends on his not understanding it."

In the meanwhile, my company spent in excess of two years, and increasingly more resources trying to build the same thing and being not an inch nearer to their true goal - I wonder how soon till the outside world starts to notice. The CEO is frustrated because the strategy is sound and he doesn't get why it's not getting done. In the meanwhile, trying to tell to the VP that the tactics is wrong (and how it's wrong, and how to fix it) gets you the axe. It's messed up, but all I can do right now is say "it's not my job to fix this mess" and play along with it/ learn interesting technologies & cash my cheques. :(

It doesn't have to be a balancing act. When I know Im going off the rails and trying to implement an idea that might not pan out, I'll do it in off hours. Yes I might be doing "free labor" but I'm usually scratching and itch and the learning process helped me.

I've made the mistake recently of being too detailed an open about the joe and it's come back to bite me since we have "gone agile". I try to be as vague as possible now. The less they know the better. We do have Code reviews by the "dev lead" since most of the other developers are junior, but luckily, I am the "dev lead".

I try to do something like "80/20" in my team. 80% of time goes to current issues and 20% goes into refactoring or experiments. Management never sees this, it's just part of the regular estimates.

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.

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.

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.

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.

Same here-- designed a system used by half a dozen major companies (MS etc).

Was having design decision overridden by a PM wh had never worked a day as an engineer.

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.

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

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.

I have trouble understanding how a 6 month investigation into anything could yield nothing but a 1 page summary. Something doesn't line up. If what you were doing was actually of value, there would be many more artifacts. If it wasn't, then at some point in those 6 months you should have figured that out.

It sound like he did multiple investigations, each producing one page long summary.

A detailed investigation can easily take a month and then you just make summary of why you rejected it - brevity is often advantage.

Yup, pretty much this. There's only so many ways to say "this doesn't fit the business case we want it for". Especially when talking to non-tech managers and executives.

It's still hard to imagine. At the point where the investigation was scoped ("looks like this is going to take months"), and the risk assessed ("there's a nonzero chance this will yield nothing except a rejection with justification"), did you decide "yes, this is something I choose to work on."?

These things don't just sneak up on you, at least not if you are planning and scoping your work ahead of time. If your workplace culture doesn't compel you to do that, you should do it anyway, so you don't get into situations like the one you're in.

I don't get what you want to say or ask. What does not sneak up?

> did you decide "yes, this is something I choose to work on."?

That's the thing about being an employee at a company: the director says "look into FooBarTech", and so you look into FooBarTech. Ultimately, I agreed that the reasoning behind the investigation - all of the investigations - was sound. Our stack is big enough that any serious attempt to swap out low level technologies is going to take a decent amount of time, and the number of people who understand the whole system to the point where they can even attempt such swaps is small.

So, no, it didn't sneak up - but it still needed to be done, and I was one of three people who could do them without doubling or tripling the required time. Each time I accurately predicted the output, but executives looking to open up new multi-million dollar sales opportunities or to increase their bargaining positions with Cloud Provider X can't rely on predictions.

That said, none of this ameliorates the fact that I effectively have 6 "unproductive" months on my record; that I'm bored to tears of doing work just to throw it away.

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

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.

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.

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.

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.

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.

I don't disagree, but how do you define a "mature" developer in this context without getting into a circular definition? Like "professional", it can easily boil down to "does what I like the way I like" if we don't share an understanding of any objective reference.

That's a fair criticism. I tend to think of maturity as:

* Separating one's immediate emotions from a decision making process

* Proficiency with perspective taking

* A basket of traits along the patience/conscientiousness axis

Those traits often improve with age which is why I tend to lump them under maturity.

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.

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.

You ascribe this to maturity, and while I agree, I think the more fundamental issue is one of developer talent and ability. Bright ideas from developers lacking these is not just unhelpful it is an active hindrance. Dealing with bad ideas takes time and energy, and people with little competence are often the most vocal.

As for maturity, what works the best in my view is to hire people of equally high competence but with different levels of experience. You need those people with 30 years experience, just as you need those right out of college. The former provides wisdom and the latter enthusiasm and optimism.

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.

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

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.

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.

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

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

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.

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

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.

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.

> If the author of this article thinks more inclusion in business decisions

Not all ideas in a dev shop are about business decisions. They could be about reporting, monitoring, alerting, code quality, technical debt, etc..

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.

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.

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

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.

You can be a resource and still make a suggestion or notice something. Outright ignoring suggestions because of rank is dangerous. In software, it’s probably a programmer “in the trenches” who first realizes that something won’t work, or that you need X in addition to Y, and it can be very cost-effective to fix these things early.

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.

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.

When the budget gets tight and they need to reduce headcount, see how well you're treated by your "family".

If my household budget got tight I wouldn't throw one of my kids out on the street.

I also haven't had 6 different families over 20 years because I didn't like the environment or by getting a new spouse I could make more money...

Or in the words of Netflix "we are a team not a family".

https://www.slideshare.net/reed2001/culture-1798664

You say that like it's an inviolable law of nature to be fucked by your employer.

It may not be an inviolable law of nature, but the power dynamic of employment is designed to never be equitable. That's always worth keeping in mind when one is tempted to seek emotional or intellectual validation from a company, which is something programmers and other creative types can fall prey to.

A story was posted here and on /r/gamedev not long ago about a game developer who quit their job and moved to a new town on promise of an interview with some AAA studio (I CBA to remember the specifics right now) but they were so emotionally invested in the hype and culture of that company that they were left in dire straits... when that company simply canceled the interview and passed them up because they said a negative thing about the studio in a forum once.

Unless you're independently wealthy, or not living in the US, and thus protected by a social safety net and strong employment laws, you really can't afford to approach the job market with anything but cynicism.

This is something I think a lot of managers fail to understand. You are not "in the club", you are not an "owner", etc. You are an employee paid by the company's owner(s) to oversee resources. You yourself are a resource. Once you start thinking that your job is about "getting wins", making yourself look good, etc. you will start running your group like a fiefdom and engaging in rent-seeking behavior, basically stealing from the company since you're seeking your own aggrandizement/comfort/job security over the bottom line for the company. And since you're overseeing realistically multiple million dollar projects, you doing so is 10x, 100x, 1000x bigger of a deal than some developer being lazy at work or trying to use the new framework so he can put it on his resume. In this sense I think poor managers are actually the worst employees.

if you made it to part 3 of the article, it's also:

tldr; programmers need to be leaders too, and schedule regular 1-on-1 meetings with their boss.

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.

Reply on news.ycombinator.com