> The company is bigger than you are, its decisions weigh heavier than yours. Stop with the ego-belief that you know better than it. It's cold comfort to be right, so just get behind management and try to make the new direction work.

I don't want to put too fine of a point on it, but it sounds like you might have missed the point of the article. The author was saying that efforts to improve business outcomes by closely managing engineering work often have the exact opposite effect of what is intended. As you soon as you start trying to measure developers you slow them down, hence the title.

I don't think it's "ego-belief that you know better" if a business says "we want to ship things faster, let's try doing X" and you see that X actually slows things down to then say, "hey let's not do X, it actually slows things down."

The author does seem to think he knows better than anxious middle managers who are overly eager to change how things are done. But, well, I'm inclined to believe that he does.

That said, there are very real concerns and worthwhile motivations that lead managers to start closely project managing engineering. And in reality free-form engineering can lead to lots of time wasted on personal obsessions, or just plain slacking. So I agree about the rose-colored glasses.

> I don't think it's "ego-belief that you know better" if a business says "we want to ship things faster, let's try doing X" and you see that X actually slows things down to then say, "hey let's not do X, it actually slows things down."

No, it's not. What is is when they say no and you persist in your belief. They said no for a reason, not grasping that reason or willfully ignoring it is a function of ego.

The author is simply describing a transformation from a system driven mostly by intrinsic motivation to a system driven by an extrinsic one.

Typically complex tasks are solved better in an environment with emphasis on intrinsic motivators.

It's not wissful thinking. It's a keen observation.

Basically management offloads the responsibility of actually managing to a process of accounting. It's a less skillfull, less productive, but a much more predictable form of management.

The problem was not the Jira. It was the new PM who instituted the cultural change. Jira can be used just a well to document work done by intrinsic motivators.

This, 100%. I agree that complex tasks are generally better solved in an environment driven by intrinsic motivation - heck, probably all tasks and not just complex tasks.

I'm not sure if Jira and other task tracking tools can be used just as well to document work done by intrinsic motivators though. I mean, yes, they _can_ be, but I don't think they're as good as they could be. In fact, I'd say there's a big gap in the market for a solution that gives non-technical managers some reassurance that progress is being made while also not getting in the way of the ad hoc workflows the post describes.

I've found that tracking tools are good to have even at times when I've been able to work in the manner of freedom the article describes. It's just that they are used differently, more in a way to help remember things. Things that either needs to be done or things that have been done. Especially those nightmarish things that took a long time to solve, so documenting the process is good for the future, in case it happens again.

It wasn't always like that for me (document, bah! comments, bah!) but as I grow older I've come to appreciate the possibility to offload information in my brain to a more persistent media. This way I only keep the index in my brain ("Hey, wait a minute, I recognize this..."). Maybe I'm just lazy but I hate doing the same thing twice. I also hate saying the same thing twice so before I explain something to someone I like to write it down and give them a copy. Then when they ask me about it I simply refer them to the document (in a friendly (RTFM) manner).

The same research that shows that complex tasks are better solved with intrinsic motivation also shows that simple tasks are better solved with extrinsic motivation. That is, measuring mechanical/repetitive work does increase its productivity.

What we have today is an almost complete lack of mechanical/repetitive work to measure.

"there's a big gap in the market for a solution that gives non-technical managers some reassurance that progress is being made"

That's not a tool gap but a trust gap in the team, and no tool can remedy that, IMO.

> The problem was not the Jira.

The first problem was thinking that you could set meaningful hard deadlines for inadequately defined goals. The second problem was acting as though they were meaningful.

> The company is bigger than you are, its decisions weigh heavier than yours. Stop with the ego-belief that you know better than it.

You sound just like a church.

Friction is good, differences in opinions and priorities are good. Especially in a creative environment. When a part of that is silenced based on just organisational/hierarchical arguments, everyone involved will become less effective in one way or another.

I do agree with you that after not being able to fix the organisational problem, walking away is not the cowards path.

As an individual contributor, your ability to fix organizational problems is limited and efforts to do so are almost inevitably plagued by wishful thinking. You're just not in a position to be able to change how people think about things. Your skillset is not with people, it's with code.

That really depends on the IC and the organization. That's probably true at some places. At a 30 person startup you'd be amazed at how much individual engineers can change things.

And here I thought I was cynical...

> Especially in a creative environment.

It is not a creative environment. We are talking about mid- to big-sized projects and companies here. Not the scrappy startup, not the open source consultant shop, not the small niche application for your Macbook.

Differences in opinions are good, provided the team as a whole is reasonably aligned. Too much divergence and this "room for creativity" becomes a schizophrenic organization.

Did the development team in this example become more or less productive after it became "reasonably aligned"?

Sure rose-colored glasses is a part of it. But at the same time, you have them too. The problem here is lack of leadership and the organization is trying to solve it with management. The parable of the loggers is apt in the authors situation.

> A group of loggers is busy chopping away doing great work under the supervision of the managers and achieving high productivity and throughput. Someone from a mountain overlooking the forests notices something and shouts "hey, you down there ..." - reply: "we are busy, and making great progress" ... and the person on the mountain yells "Wrong forest!"

I would try to leave the company, checking out mentally while waiting for the right opportunity and getting behind management helping them get the rope so they can hang themselves. Because ultimetly the company is bigger than me and if I'm not happy working there just building features why would I stay? I don't want a reputation of building buggy software, because the company I work for doesn't focus on it. The company has no loyalty to me if times are tough, because thay lay me off if times are tough. So companies shouldn't expect any loyalty to stay from me either if they take decision that are against my interests.

> The problem here is lack of leadership and the organization is trying to solve it with management.

Management is a resource that can be easily added or subtracted from an organization, leadership is not. Good leaders are rare, but management can be taught.

Yeah and management alone doesn't suffice. Only managing the adding features and not managing the quality is a problem, and as I see it lack of leadership.

You didn't seem to grasp my point.

Management is a resource a company can throw at a problem. Leadership is not. Positing solutions that can't be implemented is the very definition of wishful thinking. Calling it a lack of leadership isn't helpful. You need to break the problem down further and try to find a way to solve it that doesn't involve supermen.

The thing is that I'm only telling what the solution isn't. Solution might be, to ask the people doing the actual work the right questions. But if that is not happening or if no one is listening to the answers, the solution is for an individual to change company. Because in my experience when the shift to wrong type of management happens, it seldomly fixes itself. And as a lowly peon you can't influence enough to change a culture that isn't a good fit for yourself.

I.e. the company is ruined if you think it is. There are no solutions, you are doing the company and yourself a disservice by staying.

What the author describes is that the manager manipulated the consensus building in the team, by adding friends to the team so he can start ignoring them. Consensus building is a key part of any organization and doing this is not ethical.

Then, what you describe: reducing technical debt is a nice to have? life is too short to care about quality? That's pretty much, in your own words "the coward way": "checking out mentally".

This is almost completely wrong.

Building consensus is just one management style. It is by no means the only one, or even the only effective one. It's not unethical to manage in a different fashion. The people being managed don't like it, but that doesn't make it unethical. Just find a better job.

Checking out and doing what you're told is a rational response, one that management would not be opposed to seeing. You're still getting paid the same, but are having your responsibilities taken away. Most other people are overworked and underpaid, you're getting underworked and overpaid. So why complain?

Being able to come into work, do a job, and go home without having to be worried about the outcome of your efforts, to have someone else on the hook for it, that would be looked at by a lot of people as a luxury. But devs all seem to have this ego that keeps them from being able to appreciate the reprieve.

Yes. Check out mentally. Do your job and go home at 5 and do all those other things in your life that you've been neglecting because you were putting that energy into your job. Spend time with your wife and kids, date if you're single. Work on your hobbies. Enjoy it because that's not going to last forever either.

What I see from many of your comments, and why I think you're getting so much opposition, is that you are suggesting we should be satisfied simply being programmers while many people here on Hacker News want to be more than that.

The reality may be that many of us are just programmers and that the real struggle isn't with the project management but with our refusal to accept our role. I can't argue with that. We can't all be architects; someone has to lay the bricks and you can spare yourself some trouble, and even find some satisfaction, by accepting that from time to time someone will tell you to lay the bricks the other way. But I wouldn't demean people for wanting to do more.

Personally, I don't find programming very fulfilling. I don't get satisfaction from producing a sufficient quantity of code, but from solving sufficiently challenging problems. Coding a means-to-an-end for me, just a medium to express my thoughts and ideas like pen and paper to an artist. When my job became more about bullet-point features and timelines than the problems the system was supposed to solve I struggled. A lot. In fact I started looking for new problems to solve in lieu of the ones I had been working on, like why the project was struggling and how to convince the project managers they were just digging us deeper into technical debt.

Fortunately I'm being moved to another team as part of a restructuring in our organization and had the opportunity to explain my perspective to my new manager, who suggested I could be put on more of a leadership track. Will it happen? Will it be better? I don't know, but trying means I can see if my current employer wants to see what else I can offer and help me grow or if they just want me to sit down, shut up, and spit out some code.

> why I think you're getting so much opposition

Getting plenty of upvotes too. If I find I'm not controversial enough, I'll dig around for something more interesting to say.

> you are suggesting we should be satisfied simply being programmers

I'm doing nothing of the sort. What I'm saying is that you shouldn't let your job become your identity. Dream big, but realize that the best company to be the receptacle for those dreams is the company you build yourself. This was a hard lesson for me to learn, but ultimately it makes everybody happier; you, your SO, the company you currently work for, the people you're working with on the side.

My go-to saying for this is "Don't fall in love with something that can't love you back."

Thanks for your clarifying where you're coming from. I read comments like

> All good things eventually come to an end, and you need to be ready for the inevitable.

> You're just not in a position to be able to change how people think about things. Your skillset is not with people, it's with code.

> You're still getting paid the same, but are having your responsibilities taken away. Most other people are overworked and underpaid, you're getting underworked and overpaid. So why complain?

and it sounds like 'The professional world sucks. Deal with it.'

But with a bit of context I think they can be read in a way that should resonate with more people here, perhaps 'The professional world sucks. If you think you're ready to go out and tackle that problem then get out there and do it.'

Let's face it, you are going to spend the majority of your life at work. Is money the only thing you care about? If so, why not doing something else? Nobody gets rich being a checked out employee.

You not only get paid with money, you get also paid with experience. That experience has a market value.

If your resume reads: "mindless checked out employee in tyrannic sweatshop using 15 years old tech", your market value will be lower than "engaged employee in innovative company using cutting edge tech". So if money matters to you, you should care about investing your career in experiences that lead to a higher market value.

It seems to me that checking out mentally is only an option if you're doing mindless, repetitive work. But as Fred Brooks put it, "The programmer, like the poet, works only slightly removed from pure thought-stuff." So is it even possible for programmers to check out mentally without seriously degrading the quality of their work?

You are assuming that staying 8 hours a day in a job you don't care about is less consuming than staying those 8 hours in a job you love.

I can't even imagine where did you get that from. One will cause deep depression and burnout in no time - the other is a wonderful life experience.

I can care about doing a good job and keeping a tight ship without having to care about company politics. A job is what you make of it. As far as I'm concerned, I'm not breaking rocks apart with a hammer for 16 hours a day, and I have some bargaining power to make my lifestyle better, so why complain? I don't understand people that have to turn work into some grand quest to make the world better. I think these sorts end up making more unhappiness than they do happiness.

A job you love is a great thing. But that job is only going to last as long as the economics work, or the company wants it to last, or if you're doing the business end as well as the technical end. Once it's gone, just find another job and work out ways to love it.

> I can care about doing a good job and keeping a tight ship without having to care about company politics.

In this case, no you can't. Company politics has placed a superior of yours explicitly tasked into order you to do a bad job.

I do completely agree with the "just find another job" line. What I don't agree is with that "cheer, your job is less stressing now".

Nobody can task you to do a bad job. You do that yourself. You may find excuses for doing a bad job, but you chose to do it, they didn't hold a gun to your head.

If I find that I absolutely have to either cut corners or let the deadline slip, I let the deadline slip. I refuse to knowingly release crappy work, you can fire me for it, I don't care. But long before that deadline, I will have explored the options for changing the scope of the project so such a decision isn't necessary.

"Just find another job" isn't sufficient because every job involves making tradeoffs between personal goals and business goals. I believe in being real clear with management about what's happening so that we can work towards an equitable solution.

I'm 100% in favor of "checking out mentally". Only I describe it differently. When you start insisting on what's good for the business and your employer disagrees, there's only so far you should go, because in the end they're paying you to do what they (possibly unreasonably) want. It's okay to push back against micromanagement, but that should be viewed as a selfish struggle for better work conditions (or better pay to compensate), not a selfless struggle to make the company better.

"I mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about."

wat

Sounds like a 'you have a better than average income so you shouldn't complain about stuff'. Two problems:

1. Fiscal income is not the end all be all of determining quality of life.

2. The argument itself doesn't work; one only needs to apply it to others to see how it works. Take a poor person on welfare and tell them they don't have to worry about things that people in third world countries where welfare doesn't exist do. The whole 'how are they poor if they have refrigerators' argument. You quickly see how empty the argument is.

>magic

The success/failure of a project hinges on lots of things. Amongst them, code quality, which heavily dictates your reactivity. Having a technically-blind management isn't going to work, especially if it leads to policies like "no refactoring" or "no time for tests".

Another thing: high-tech is an innovation-driven market. Most of the ideas are going to come from your developers, so why adopt a management style killing their creativity?

> Having a technically-blind management isn't going to work, especially if it leads to policies like "no refactoring" or "no time for tests".

That's the entire idea of technical debt. It's just like real debt, only that it's cost is development time. And it takes time to pay it down. The only difference is that it's not reported on a balance sheet, so management doesn't care about it.

It's their codebase, they paid for it. If they don't want to maintain it properly, then it's on them. It will just get more and more expensive to maintain until they replace it with newer technology.

Developers fetishize their codebases and complain about unpaid technical debt, but not all the bad code I've run across I can push off to management making the wrong decisions. I've seen a lot of bad decisions made by the original developer too, who just did things improperly.

Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt. If you're incurring technical debt, then you need to spend some time analyzing it and coming to a real understanding of the tradeoffs you're making in doing it a certain way. Hopefully you'll have documentation somewhere that describes the debt, what's being worked around, and what it would take to do it right.

If you're not doing that, then you're just leaving a mess for the next guy. Messy work isn't technical debt, it's just sloppy work.

> It's their codebase, they paid for it.

> Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt.

You can't have it both ways. Either the employer owns the code and is responsible for monitoring and managing technical debt, or it's the dev's responsibility and the employer needs to make that clear and hire people who can balance decisions effectively.

> You can't have it both ways.

Sure you can. They paid for the codebase, it's theirs. You don't own it, whether you have the responsibility for keeping it maintained or not. That's true no matter which approach the company takes to managing their technical infrastructure. They can make decisions about it with or without your input and there's absolutely nothing wrong with that. It's theirs, not yours.

What you own is a responsibility to that codebase and to that company. A responsibility that the company is paying you for. It's your responsibility to not fuck up that codebase. If there are conflicts, you need to bring them up to your employer and let them make the decision.

What I think you're not getting is that tasks like cleaning up, refactoring, etc. are part of the job and that you're not doing your job properly if you don't do them. You do not bring these up to your employer or allow him to stop you from doing them, because they're part of the job.

If you work in construction, clean up is part of the job, you don't ask your boss whether you clean up or not, you clean up and he pays you for the time. Same with dev work. It's not up to them, you are a professional and nobody should tell you how to work. If they don't like it they can fire you, and you can go somewhere that appreciates your professionalism. You'll probably get paid more too.

> You do not bring these up to your employer or allow him to stop you from doing them, because they're part of the job.

I agree with that. Don't need to discuss how sausage is made. OP was pointing out that there are circumstances where the sausage making is micromanaged, which puts a kink in this plan.

Wouldn't put a kink in mine. I'd just carry on as usual. When I write code, I don't release it until it's been cleaned and refactored to my satisfaction. If a micromanaging boss wants to know my progress, the answer is simple. It's not done. He wants to know why, I'll tell him. I'm not happy with X class and I'm cleaning up the methods and reorganizing it. Should only take another hour.

If he starts getting 1984 on me and demanding I cut it short and deploy, then it's time for a closed-door meeting. He might be my boss, but he's not telling me how to do my job.

> He might be my boss, but he's not telling me how to do my job

100% agree. If more developpers shared this attitude, world would be a better place!

Honestly, I love that attitude. Also, be prepared to be shown the door.

I agree with many of the points you make, I don't agree with your assignment of blame. Good developers can make bad decisions. It's just that it may not be seen for a year or two. In a SaaS platform it's hard to see around a corner a year from now.

The thing about technical debt, is that once you have accrued it, it doesn't really matter how it got there. You either accept it exists and carry the balance or fix it. And typically, it's the role of management to recognize this.

You seem to forget that most of the best coders have spent countless hours learning a ton of things. It's not something easy or without a tax on the mental.

I found it easy enough. I learn new things for fun. I don't consider it taxing at all. Anyone who wants to pay me to learn something new, I'm happy to oblige them.

> I found it easy enough. I learn new things for fun. I don't consider it taxing at all

I have no doubts that you find learning fun and find it easy, but the last sentence I'm a little hesitant with. It reminds me of a single pane comic strip I recently saw. It was of a business man receiving a logo from a designer, and he said, "Why should I pay you $X dollars for a logo you designed in ten minutes?". To which the artist replied, "It took me ten years to get that quick at making logos." Learning the art of software development is similar, you need to get a solid foundation in your domain of knowledge before you can build anything both well and quickly or before you start to find things easier to figure out.

I would like to stress that programming is very hard and taxing when you are completely new to it and it progressively gets easier and easier. I only was recently re-informed of how hard programming is as I have recently helped my brother begin programming, because like you for the most part I find it relatively simple to learn something new. Though I find it easy to learn I notice when I first dive into a new framework, language, or codebase I do have to watch my stress levels and make sure I'm not getting overwhelmed by it.

>I mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about. These finer qualities of career enjoyment are nice-to-haves, not necessities.

If by wizards you mean everything they do seems like magic to everyone who has never written any code and themselves and their methods are often misunderstood I would say that is true, and I think that may be part of the problem. Though some might oppose it I think the idea of educating more people in CS in grade schools might help combat that.

To the second sentence, I would say everyone has their own measurement of what a necessity and a nice-to-have is, but often most things people complain about aren't completely necessary. You can tell he (the blog poster) has a problem with the way things are being done at his company I appreciated his opinion although I don't necessarily take his stance.

There's an art to learning. I work on that too. The better I get, the quicker it takes me to integrate new ideas.

> Learning the art of software development is similar, you need to get a solid foundation in your domain of knowledge before you can build anything both well and quickly or before you start to find things easier to figure out.

If you look at all the other skilled professions you'd find similar dynamics. You spend a lot of time paying your dues. Once you've paid them, then you have to learn how to turn them into a career. What's unfortunate about development is that there's never that moment where you call yourself done with the skill-building part and start on the career-building part. Other professions have that, but development does not and probably never will. It's too big, and changes too much for an examination to be worthwhile.

> If by wizards you mean everything they do seems like magic to everyone who has never written any code and themselves and their methods are often misunderstood I would say that is true, and I think that may be part of the problem.

That sense of magic is what keeps salaries relatively high compared to other individual contributors. It also means that we can cloister ourselves into priesthoods where those with the arcane knowledge can band together against the uneducated masses. I used to think coders needed a union, until I realized we've already pretty-well self-organized into one.

I'm guessing you're new in this trade.

I envy you. Mostly being a programmer learning "new" things is the same as a taxi driver moving to a different city every half year and learn the new topology.

In both cases, you're not learning anything that is fundamental to human knowledge.

Well, unless you're a research scientist, nothing you ever learn is fundamental to human knowledge.

But depending on what you spend your time learning, you can improve in your craft. I think that is valuable. For some people becoming excellent craftsmen gives them purpose in life.