Heisenberg Developers (2014)

http://mikehadlow.blogspot.cl/2014/06/heisenberg-developers.html

by Sidnicious • 10 years ago

315 189 10 years ago

mikehadlow.blogspot.cl

donatj3• 10 years ago

This is exactly where my job is headed. We hired a project manager who frankly knows nothing about tech. Suddenly, we the developers are no longer able to file tickets ourselves and the tickets themselves need to be blessed and have specs the higher ups can approve. One liner for a hot fix that's filling the error logs? Needs a ticket - a ticket we can't file. All pull requests need one or more associated tickets. I've done my best to actively ignore/subvert it, but it's coming up more and more.

It's incredibly stifling and frustrating and I'm really peeved. It's hard to leave a job I love and have been at for almost 5 years, but we're on a road to hell.

All that said, if anyone needs a Go dev ;)

partycoder9• 10 years ago

The problem is not creating tickets. It is the process around them.

Creating a ticket takes seconds and you can even build templates around them if you think they're time consuming. If you cannot report tickets your workflow is wrong.

twunde• 10 years ago

Seconded. You should be able to create tickets or at least file an initial ticket that a PM can flesh out. Tickets (or any type of change control system including git) really serve two purposes. 1) To track what changed 2) To track WHY something changed. A dev should be able to look up your ticket a year from now and be able to untangle the logic in your code changes tied to that ticket. If your ticket only has a title, or the briefest of descriptions you'll find it hard to debug any issues introduced by this (and you'll also be going to dev hell)

clockwerx• 10 years ago

Simple fix: apply inner platform effect to your benefit. Either highlight a 'high level feature management tool' (trello/wrike/etc) different to your development workflow, or abuse the current tool by requesting very generalised tickets like 'standing outage prevention' (maintenance!). No one will reject that because the consequences are lots of revenue.

seivan4• 10 years ago

Every time I read something like this (because experiencing is just to traumatic to remember) I tend to share http://algeri-wong.com/yishan/engineering-management.html

One day I hope to find some place small that applies that by the 'book'.

My personal anecdote was, that no matter how much I tried to persuade the PM that it's a bad idea to put all the platforms (iOS, Web, Android, etc) stories and bugs into one giant tracker (Pivotal Tracker) we ended up doing that.... until the sudden realisation that it's a bad idea. It's hard to believe that PM had been on software projects before.

Found a typo in what is otherwise awesome writing, "loosing".

allengeorge• 10 years ago

Why is this a problem as long as bugs are separated by component? Sometimes a feature will require work on multiple platforms, and it's nice to go to one place to get a sense of overall progress. And, since the bugs/tasks are separated by component, you can get the granular view you want as well.

ViViDboarder2• 10 years ago

As a developer, I love having tickets linked to changes! It makes it trivial to trace a git merge to a review and then the original use case.

This allows commit messages to be more succinct and technical.

Also, if your company is publicly traded in the US, there are requirements to document changes from SOX.

donatj3• 10 years ago

We're privately owned, but that is an interesting thought I'd never even considered.

hlieberman• 10 years ago

This is very true. My experience has always been that my team performed better when there were /less/ controls on their time, rather than more. I also found it was important to explain the reasons /why/ a particular thing needed to be done by a certain date, on the occasions that some external pressure needed it to be done.

People don't mind pulling out the stops and working extra hard, as long as it's occasional and /necessary/. It's absolutely morale-killing to do so for an arbitrary deadline, however. Nothing burns out a team faster than death-marches to deadlines pulled from thin air.

jaggederest2• 10 years ago

And of course, the other key part of that is that you should consider those exceptional cases to be exceptions, in the sense of errors.

When production goes down, or the sales team overpromises, don't just fix it, figure out why it happened and do the full root cause analysis.

CryoLogic4• 10 years ago

One issue with how developers are hired these days, is many large companies are hiring largely for classical knowledge (aka, memorizing: Algorithms, DS) and mathematical ability. Try interviewing at MS, big G or Amazon and you will see what I mean.

These developers are great as code monkeys, but a lot of them don't have any idea what their code contributes to, or even how their business makes money. I attended a hackathon with a number of Amazon employees, and one of my distinct memories was a Principal Engineer who didn't even know what "publicly traded" meant and was sure that Bezos owned 100% of the company.

A potential solution to this issue, is to hire engineers with more diverse skillsets. Deep understanding of mathematics and classical algorithms is fantastic for software performance, and low level details.

On the other hand, at a tech company - your software is literally your revenue stream. You are hiring people who don't understand your business - to build and grow your business.

Maybe hire some developers with strong business skills, and a good understanding of the economy and your market - and put them on a team with more traditional engineers. In doing so, you get someone with the big picture, and someone with the details working together and might not even need another PM.

Just my thoughts.

TulliusCicero• 10 years ago

That sounds like a good idea, until you realize that developers with a strong grasp of coding AND business are rather rare. If you're a growing business, it's hard enough to find enough really good devs as it is, and now you want to add in another, orthogonal skill set? Good luck with that.

ilostmykeys• 10 years ago

Ask not what your left or right brain can do for you. Ask what both of them combined can do for your company.

paulus_magnus2• 10 years ago

Geeky (single focus) developers are - cheaper

- do not get distracted by politics / business

- easier to control / manipulate into lower salaries

partycoder9• 10 years ago

Lots of cognitive bias there.

pc863• 10 years ago

I seriously doubt there's any supporting evidence for the idea that people focuses on coding over business have any trouble negotiating a reasonable salary.

rorykoehler7• 10 years ago

Anecdotal I know but I've been told that my business knowledge and curiosity is not welcome nor wanted whilst developing and that I should be more single minded to churning out code. We live in an economic environment where specialisation is valued over all else. Polymaths and generalists struggle in this environment unless they found the business themselves or are lucky enough to get picked up by a large company to head up a team.

CryoLogic4• 10 years ago

I spent my teenage years building fan sites and social networking sites for games. I made enough money to pay off college, get a nice apartment by the water and have a couple k leftover come graduation.

I was curious why I wasn't getting a lot of hits on my resume, so I talked to a recruiter at a networking event who had seen my application (for one of the "unicorns") and she said they where uncomfortable with how entrepreneurial it looked.

I removed the sections from my resume, removed all of my contract work too - only listed the internships and found some other grads (that got jobs) resumes to copy the language style. Pretty much instantly my resume was getting me double or triple the interviews.

Bummer too, because I worked my ass off and always had the false impression that employers would like that.

Sometimes its the gap between marketing (how they want the company to appear) and HR I think. Marketing wants innovators, HR wants workhorses that move in a strait line and don't try new things.

bcjordan5• 10 years ago

You're right, sounds like maybe a bit of over-generalization from your situation :)

Do you have a direct manager who talks with you about your career growth? A good one might help you find projects that engage your broader interests. There are certainly roles and projects that involve some degree of inter disciplinary work, and not just at founder or team lead levels. If not at your company, there are certainly some at others. Startups especially welcome diverse contributions from early employees.

Hope you find a good outlet for your interests! If not in an engineering role, maybe try a side project.

chime2• 10 years ago

That's a sign that you have what it takes to start consulting on your own. Every client I've ever had has appreciated my non-programming skills. I've never taken a client until I thoroughly understood the business and I have rejected many potential clients because I did not agree with the business-end of the software need.

Specialization is indeed valuable but it's not a binary master-of-one vs jack-of-all market. I am A+ in a specific platform, A in a couple of market segments, B+ in a handful of valuable technologies, B in many professional skills, C+ in most business activities, and C in everything that I have never encountered before. I don't need to be A+ in everything I touch and I am definitely not just a C in every single trade.

You don't have to start a business or be lucky enough to head up a team at a large business to get a chance to apply your skills fully. I don't want to do either so I consult with small-to-mid-sized business and research+plan+code+test+train whatever they need. For someone on a W2, this seems unconventional and risky. Don't want to sugar-coat it - it is. But what it's not is unsatisfying.

If you are in a position in life to take a small risk on yourself, pick up a small consulting gig that is more than just pure coding/technical. The more you perform like a vendor and business partner and less like an hourly contract employee, the closer you get to applying your full range of skills.

golergka3• 10 years ago

Don't work in a company with the people who told you that. It's not only wrong, it's bad for business, and I constantly see the negative consequences of this worldview.

pc863• 10 years ago

I think it depends on the job for which you're applying.

We want our senior developers to be willing to dig into business requirements and constraints without being asked to. Curiosity, orthogonal business knowledge, etc are important at that level and higher.

However, we've seen multiple times that the junior developers just can't do it with the rare exception. They have enough work getting up to speed on one or more of: the language, the large internal system, the large client systems, how the client works, how to be an employee, how to deliver value over the long term and not go 2 weeks with no delivery then 2 weeks with, etc.

__jal• 10 years ago

Like anything, it depends. If you don't like being a cog in a large machine, look to smaller shops. I hate working in large firms precisely because I'm bad at shutting up and being a cog.

And you know what? In big shops, painting outside of your lines actually can cause problems. Questioning decisions on things going on outside of one's domain causes slowdown (at the very least, wasted time in meetings where people explain why that stupid idea actually has to be that way, etc.) and frequently, conflict, because when the norm is "stay in your (metaphorical) cube", questioning decisions can all too easily look like an accusation of incompetence or as a power play.

Go where your other skills have value.

edderly3• 10 years ago

Off topic, but that doesn't resonate for me.

Can't say much for MS, but for the others the essential CS skills questions (should be...) relatively uniform for all experience levels. i.e. they are at graduate level.

Plus, Amazon count on these 'a lot' https://www.amazon.jobs/principles

Possibly more than the CS side of things in my experience.

eyko• 10 years ago

Triplebyte has a blogpost[1] that seems quite relevant. Most companies seem to want "product programmers"[2], as opposed to technical or enterprise programmers. The second link below is another blogpost by them explaining this taxonomy.

It would be interesting to see how much this applies to non y-combinator companies (which is what their study covered), but I'd have a guess and say that, for most startups, quite a lot.

1. https://data.triplebyte.com/who-y-combinator-companies-want-... 2. https://data.triplebyte.com/a-taxonomy-of-programmers-d0e9d8...

pc863• 10 years ago

I attended a hackathon with a number of Amazon employees, and one of my distinct memories was a Principal Engineer who didn't even know what "publicly traded" meant and was sure that Bezos owned 100% of the company.

This is terrifying. I wouldn't be surprised if his 401(k) was 100% Amazon stock "because that's where he works" or something.

amag3• 10 years ago

100% of what stock, didn't Bezos own everything?

scandox• 10 years ago

My experience in interviews is that my interest in and focus on the end product and business make me appear more lightweight technically. "Not enough of a nerd"...basically.

DanielBMarkham• 10 years ago

I agree. In fact, the more I look at this problem, the more convinced I become that coding shouldn't be an end to itself. Very few companies need super-smart generic programmer cut-outs. Instead, they need business folks who can program.

It makes sense if you think about it. If software is truly eating the world, it's an upheaval on the scale of writing. Nobody hires specialized people to write; that's idiotic. Writing is so closely associated with what we do day-to-day that whatever your job (in the business sector), you're expected to be able to form a sentence and write it down. Same goes for programming.

I have no idea how long it will take to fully make the transition. A hundred years? Twenty? It'll be interesting to watch, though!

philh2• 10 years ago

I attended a hackathon with a number of Amazon employees, and one of my distinct memories was a Principal Engineer who didn't even know what "publicly traded" meant and was sure that Bezos owned 100% of the company.

It's not clear to me why that knowledge would be especially useful to a principle engineer at Amazon. I think it's a generally good thing to know, and difficult to avoid picking up. But clearly someone did avoid it, and I don't particularly expect that to reflect in their engineering competence.

throwawaymsft4• 10 years ago

What would you think of a government employee who didn't know the US was a democracy?

dragonwriter2• 10 years ago

It's not clear to me why that knowledge would be especially useful to a principle engineer at Amazon.

Assuming that Amazon has any equity portion to compensation (which is common in even large tech companies, not just startups, though I don't have any direct knowledge of Amazon's typical pay arrangements) its pretty critical to understanding what he is getting in exchange for the labor he provides, so there's that.

oneJob• 10 years ago

What is it about programming as a profession that attracts people who believe they are all things? When becoming a civil engineer do you take a large number of business courses? When becoming an electrical engineer do you take a large number of business courses? When becoming a doctor do you take a large number of business courses? When becoming an astrophysicist do you take a large number of business courses?

Why are you not suggesting that ethics should be a larger portion of the programmer's training and skill set. Perhaps while building the infrastructure for the next century we should all think long and hard about the ethical implications of what we're building rather than just racing to get the next round of funding or a positive report by some Wall Street analyst on the other side of the country.

Most code bases look as though they've been built by business analysts rather than professional software engineers. The number of security exploits is a testament to this in practice. What we have here is basically a repeat of Wall Street's bond market in the 80's, just in a different industry. Because of the market fundamentals most any idiot was making a killing. Most of these bond traders actually were not terribly bright, but they were making money hand over fist, and so, they thought they were geniuses. In the end it really didn't work out well for anyone. For a good overview of what I'm referring to you can read "Liar's Poker."

Eventually these idiots were replaced with professionals, and to work at any of these shops one must now first prove, through both schooling and certification, that one has a solid grasp of a large knowledge base. If you want to become a portfolio manager, and you already graduated from Columbia with a degree in finance, that's great but you still need to go get your CFA. Google CFA and then compare that to your average programming interview. Just the Level 1 exam has over 3,000 pages of material. There are 3 levels. You basically don't have a social life for 18 months. And most of the time this is something one does while holding down a full time job that already assumes they own your free time. Lawyer's bar exams and the Board Certification process are equally grueling.

I'd be very happy with more of an emphasis on classical knowledge. A strong foundation based on a knowledge base of classical knowledge is the foundation of any professional engineering society. Patronizing someone with a firm grasp on this knowledge by saying that they are "great as code monkeys" betrays an enormously immature approach to one's profession.

klochner• 10 years ago

Many developers prefer to work like Navy Seals or Jazz Musicians. It's objectively more empowering, arguably more fun.

Some jobs require an army or a big band, i.e., a lot of coordinated precision - objectively less freedom and autonomy, arguably more tedious.

Beyond some threshold of granularity you will crush morale though.

Do what makes you happy.

ZigmundFreud• 10 years ago

I think context is important here. What is the software you are building? Is it highly critical or possibly life threatening, like a stock exchange trading system or a aeroplane control system? Should the developers be given autonomy to speed delivery? Or should more controls be put in place to ensure delivery of the quality, validated product while possibly slowing down the delivery speed.

YZF• 10 years ago

The story begins with a new feature request that the "business" thinks is needed while the "developers" think is not. It's really hard to pick sides here without knowing more about the specifics. I've seen situations where developers are completely wrong about the business value of something and I've seen it the other way around.

If the new feature was indeed critical to the business then the boss finds himself in a situation where one of the best developers spends months trying to build some DSL and comes back with nothing. So we can understand the frustration on the business side of things. This is where things started going the wrong way and there's a loss of trust on the ability of the technical team to deliver.

Now obviously the new PM and his buddies (I've seen this before) only make everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by the old team used to doing whatever they wanted to do.

I think the truth here is there has to be some sort of balance. Developers need to balance architecture and refactoring with delivering new stuff. They need to listen and have a dialog with product management about new features. There has to be trust. When there is trust there are less controls. When trust is lost it's almost an unfixable situation especially when you have a combination of a tech team that isn't delivering anything useful (from the business perspective) with management who doesn't understand software development.

Clearly the best situation is trust combined with good management and developers who take ownership and see the big picture. Then useful stuff gets delivered and things like architecture or refactoring get taken care of.

bb886• 10 years ago

Now obviously the new PM and his buddies (I've seen this before) only make everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by the old team used to doing whatever they wanted to do.

Everything I have read about agile is that if you do it right, everyone is happy. The customer, the developers, and the managers. Agile itself is supposed to be development-centric.

Tonight, I realized that Agile does not handle politics very well. I mean, how can it? It's just a software development methodology.

mannykannot2• 10 years ago

Everything I have read about agile is that if you do it right, everyone is happy. The customer, the developers, and the managers.

So they said about all its predecessors, as well. Pretty soon, they start adding "...of course, you must have exceptionally competent people", and then they define 'doing it right' by 'having a successful outcome'.

Problem solved by begging the question.

marcosdumay5• 10 years ago

Take a read at the Agile Manifesto, and I doubt you'll find any point there to criticize.

But then, take a look at any agile methodology, and try to explain how it fits the manifesto. Or better, explain how adopting any "agile methodology" fits the manifesto by itself.

marcosdumay5• 10 years ago

"business" thinks is needed while the "developers" think is not

Some correction here: "business" thinks is needed, while "developers" think is impossible. Have you really never seen that happen?

Then, a developer gets a great idea that turn an impossible idea into a possible mega-project. But, for lack of experience with this kind of project, thinks it's an small, viable one. Then, the project fails - big duh.

What's a problem here is that all it takes is one instance of this happening to the management to declare its team a failure and replace everything. Without any inspection or introspection. That's (if the history is complete) a profound lack of professionalism.

kasey_junk4• 10 years ago

It turns out that software development is a very immature industry. We simply don't know how to judge successful software projects/developers.

In the face of that immaturity we can try all kinds of things. Personally, I do anarchist development and hope for the best. Others try cargo cult project management. Still others move to highly constrained development methodologies.

gearoidoc6• 10 years ago

I think its easy to judge if a software project was successful (eg. Did we launch? Did we deploy that feature?).

The harder question I suppose is whether it was successful and we've got/maintained a quality codebase.

kasey_junk4• 10 years ago

But compared to what? Most software continues to be bespoke/new work. If a different team/process was used would we have been as successful/spent as much money.

partycoder9• 10 years ago

that's the same by saying your kids are successful just because they were born.

partycoder9• 10 years ago

Successful software is software that implements its functional and non-functional requirements at a reasonable cost. There.

kasey_junk4• 10 years ago

Yet interesting enough, that definition doesn't mention any of the actual reasons why you'd build software and doesn't speak to end-user/customer/client happiness.

It also implies at least, that we can collect requirements in some adequate way, which is really a circular argument. Requirements gathering is even less mature than other parts of software development.

vinceguidry17• 10 years ago

This is one of those wishful thinking rants that serves to highlight the rose-colored glasses many developers see the business world through. All good things eventually come to an end, and you need to be ready for the inevitable.

The author described two perfectly good responses for this scenario, and managed to paint them both as the cowards path. Leaving the company, and checking out mentally, letting the people with the responsibility hang themselves with their own rope. 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 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. There's always good, solid ground to retreat to in case you get routed. Complaints like this remind me of a rich wanker bitching about the valet not putting his seat back the way he left it. Just adjust it yourself and move on with life. Life's too short to get mad about stuff like that.

gearoidoc6• 10 years ago

"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

746F7475• 10 years ago

magic

Lawtonfogle3• 10 years ago

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.

hartator• 10 years ago

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.

vinceguidry17• 10 years ago

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.

bsandert• 10 years ago

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.

vinceguidry17• 10 years ago

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.

rglullis• 10 years ago

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.

partycoder9• 10 years ago

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

vinceguidry17• 10 years ago

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.

Ace172• 10 years ago

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?

bb886• 10 years ago

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.

fsloth2• 10 years ago

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.

skewart3• 10 years ago

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.

mannykannot2• 10 years ago

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.

skewart3• 10 years ago

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.

vinceguidry17• 10 years ago

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.

cousin_it• 10 years ago

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.

JanneVee3• 10 years ago

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.

vinceguidry17• 10 years ago

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.

gearoidoc6• 10 years ago

Some good points but the argument that software teams will be most performant as a result of autonomy really depends on the team in question.

I worked on a small team with 2 other developers who were both pretty good devs technically. However they treated the business side with almost-contempt and they would estimate even simple changes to take days.

As the most junior member on the team I couldn't really influence them. Interestingly, after about 2/3 months on the job, the business side decided to use me as their initial go-to for dev.

bcjordan5• 10 years ago

This stands as an interesting broad strokes story from a developer's experience at a growing company, but worth keeping in mind it's one specific scenario and one perspective on it.

In the generalizations-from-this-instance part of the essay, watch for two false dichotomies—"developers that care about getting things done fast with little technical debt and hate having PMs" vs "mercenary developers who like doing one small thing at a time without architecting things themselves, don't find fast ways to do things and ps like cars and money instead of hacking".

And "no PMs or process at all" vs "way too much process causing poor development time investment".

The best developers, team leads, PMs, etc know when to introduce new processes and team members and when not to. And, importantly, how to tailor processes to each team member to make them as effective as possible. And they work together collaboratively to solve problems—estimating and discussing features flexibly, not tossing pie in the sky specs and finished products over the fence.

In this instance it sounds like they didn't do a great job of working with existing scrappy developers' potential, but instead supplanted a new framework (eng/PM) they had seen work before, and the blunt hammer of that move destroyed a lot of potential the early team had invested in. It sounds like there was a general communication issue that was crippling the team even before a producer and new hires came in.

I've seen a few teams now grow from no dev process to combinations of issue trackers, estimates, specs etc. Around 14-20 developers it becomes nearly inevitable for someone to take on a high level production role and someone to take point for engineering reliability, whether those are official job titles or not.

Often this period coincides with when early team members move on. It's rad when growing companies find ways to keep those early, scrappy hires with deep historical product knowledge in productive roles as the company grows and shifts priorities from staff-leanness and product-speed to staff-scale and product-predictability. But that's often unfortunately not what happens, and it can be extremely painful for both early team members and those trying to evolve the company. (Growing pains!)

zwegner• 10 years ago

Great article, this echoes a lot of my frustrations working in the software world. It doesn't help that I've experienced being on a well-managed software team working on interesting problems--it kinda spoiled me for all those other jobs... :)

Anybody have any advice for escaping this? I want the freedom to work on interesting things in my own way with a minimum of the politics. Ideally a PM would be someone who pushes back on all this micromanagement crap and does everything they can to make the developers' jobs easier. It seems I'm not self-motivated enough to do freelance work or start a start-up, so what other options are there?

bcjordan5• 10 years ago

It sounds like you were at a company you enjoyed before—are they still hiring? :P

If not, maybe you can do another job search and try to select for companies that manage their projects how you'd prefer. Try asking team members what the process is like and how they feel about it. Often times those Qs are more illuminating than ones about the software stack.

willvarfar• 10 years ago

Ah the "lets make the project cooler by adding a DSL so customers can add their own features!" never ever pans out! ;)

I spent the 90s working on office automation projects that always seemed to degenerate into report DSLs. Is nothing new?

The better I get at coding the more I am attracted to avoiding complicated tooling.

gearoidoc6• 10 years ago

There's always a flip side! My current project has a DSL (not written by me) and it functions superbly.

It does take about a full work day to wrap your head around though :)

fidz• 10 years ago

The better I get at coding the more I am attracted to avoiding complicated tooling.

Could you tell me your story?

abalone2• 10 years ago

So a project was "months" behind schedule, they implemented an agile process for tracking tasks, and "everything slowed"? Slower than what? Being months behind schedule?

I get that some PMs can undervalue refactoring code / minimizing technical debt, and that's super frustrating and shortsighted. But the basic premise of this criticism of agile process is deeply flawed:

1. The claim that features took "longer" to ship is directly contradictory to the admission that the project was months behind schedule.

2. If they were behind schedule, then "inflating" their estimates in response to a detailed tracking process was not, in fact, an inflation. It was a reality check.

Estimates are really hard. But the solution is not to just "give autonomy" with zero estimation, because that's how you get into that problem they had in the first place: a guy in a room that doesn't ship for months. That's why agile's approach of breaking things down into tasks with very rough sizing and measuring actual after-the-fact time and shipping small milestones frequently is so helpful. You don't have to have super accurate estimates. You just need to report your time and then it figures out a team "velocity". That helps teams be more predictable, which is what it means to be professional and deliver things to customers on time.

Joeri• 10 years ago

Yet agile implemented top-down without team ownership of what to work on is not agile and not good for the health of the codebase. I have seen it fail repeatedly.

Basically, if your team is skilled and capable, the process is not that important, as they will find a way to get things done. If the team is not good, the process won't make them much better. The key to a smoothly performing software dev team is good hiring and good coaching.

abalone2• 10 years ago

So if you're behind schedule, your team just isn't skilled enough? That's kind of a dodge. Every team can improve.

Instead of exclusively focusing on finding "good" developers, let's also focus on evolving "good" process. Time tracking, estimates, itemizing tasks.. these are in fact good things.

option_greek• 10 years ago

Sometimes I feel JIRA is the manna (http://marshallbrain.com/manna1.htm) for software developers :(

edderly3• 10 years ago

Not 100% convinced by the conclusion. There is good project management which can be relatively fine grained, but it doesn't have to be micromanagement and it doesn't have to be a death march.

There are some basic red flags raised:

Our project manager would be displeased when tasks took longer than the estimate and would immediately assign one of the other team members to work with the original developer to hurry it along.

Shouldn't happen just at the whim of the PM. A sane environment would work by a developer asking for help first, and it actually sounds odd that you have capacity for a PM to throw someone to just 'hurry up' tasks

Whenever there was any debate about refactoring the code, or backing out of a problematic feature, the new guys would argue against it, saying it was ‘ivory tower’, and not delivering features. The PM would veto the work...

Why does the PM have a veto? No technical lead or management with balls? PM's need to manage the features of a release and changes to the plan. Any PM who says features are set in stone isn't doing their job. A PM's role is to handle change and execute the plan. Sounds like weak management.

vfc12• 10 years ago

Shouldn't happen just at the whim of the PM. A sane environment would work by a developer asking for help first, and it actually sounds odd that you have capacity for a PM to throw someone to just 'hurry up' tasks

The problem is that if the PM decides to do that, the developer has no authority to refuse that.

Any PM who says features are set in stone isn't doing their job. A PM's role is to handle change and execute the plan. Sounds like weak management.

Most PMs are just proxies for business, they manage up and out but not down. They will not risk their jobs by refusing requests from business, in the long term that would put them in an unsustainable position.

ViViDboarder2• 10 years ago

Maybe at some companies. Where I work, Engineering Managers and PMs are totally separate. So Engineers have much more representation.

But, even in places where this is not the case, they are willing to hire-- spend money - - to speed the project up. If it's made clear, not just to the PM, that it's going to cost money and have no positive effect, it should be a clear business decision.

pacaro• 10 years ago

The moral of this story is that "let's create a DSL so that users can encode their business logic" is jumping the shark. I was mildly disappointed that the hero of this tale (the PM) didn't fire the "DSL guy" on day one

bcjordan5• 10 years ago

DSLs for stakeholders aren't always bad. DSLs thrown over the fence without early and regular stakeholder testing are usually bad though :)

nostrademons• 10 years ago

The more projects that I've shipped from conception to completion, the more I'm believing that there are two fundamental phases for each project, and you need radically different management philosophies for each.

Phase 1 is "will it work?" You get a vaguely-specified business requirement, maybe some intuition that a market could be better served by software. And your job is to build that software, and figure out exactly what's required for it.

In phase 1, you need the creative-genius programmers, and they need to work in small teams with large amounts of autonomy. Because most of what goes on in phase 1 is failure: you are learning about the problem space and all of its corner-cases, you're trying out different approaches, and you're hoping to make that one creative leap that brings everything together. Prototyping is invaluable, refactoring is important, and deadlines and estimates might as well be plucked out of thin air. To successfully run a phase 1 project, you often need to be able to redefine success. When I read the article, my first impulse was to say "Well, the biggest fuckup management made was to not cancel the feature, because they had ample evidence that this feature was not worth the cost." A startup's entire life is spent in phase 1, because once it's exited phase 1 it's called a "high-growth company", and their version of redefining success is the pivot.

Phase 2 is "make it work". You start phase 2 with a working prototype that demonstrates the feasibility of what you're hoping to do, but still has a lot of rough edges. And your job is to polish it down to something that the customer wants to use daily. That means fixing bugs, improving usability, adding admin tools & logging, improving performance and reliability, ensuring security, etc.

In phase 2, you need a much larger team of disciplined, detail-oriented engineers. Because debugging can be parallelized. You need unit tests, you need formal processes, you need issue trackers, you usually need PMs or management. It helps to break things into user stories so that you know you're always making progress.

I see a fair amount of hate for Agile and Scrum on HN, but these are tools, and specifically tools for Phase 2 work. I use them myself, for my own projects, because I find that they help me manage all the little tasks involved in bringing a product to market. The hate comes from people who misapply them: startups who have big-company management who blindly apply what worked at their last employer, or established companies that are trying to do new green-field projects and believe it works the same way improving your 10-year-old product works. But similarly, there are a large number of abandoned startups and open-source projects that never bothered to cross the Ts and dot the Is, and so are largely useless to people.

sheepmullet• 10 years ago

The more projects I work on the more I am convinced most projects are a combination of phase 1 and phase 2 work.

The biggest problem I see is projects usually adopt a one sized fits all approach.

If part of the team is using a strict scrum process and they find it helpful because they are doing phase 2 work then all of the team gets forced into it even if they are doing phase 1 work etc.

gyardley• 10 years ago

Oh, the joy of being a product manager for the particular type of programmer who, by virtue of being a programmer, also knows absolutely everything about absolutely everything.

This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month, but if they disagree with a tiny aspect of the feature you've brought them, the deep domain knowledge you were hired for and dozens of customer visits you've done are nothing in the face of the awesome might of their computer science degree. Better get comfortable, because it's going to take you several hours to persuade them that you do in fact know how to do your job and the wild-ass alternative they've just come up with is wanted by the market about as much as syphilis.

With these guys (and they're always guys) you've got to process up and micromanage, because the only way to get a little bit of intelligent estimating out of them is to ask for ten times as much, so they can give you what you need while still feeling like they're largely ignoring you. The only silver lining is the process eventually makes them leave, so they can be replaced by people who work well with others.

You know, I really don't miss being a product manager.

Ranting aside, good developers in larger organizations realize that people have specializations, they and other parts of the company are interdependent, and a little administrative overhead is necessary to keep everybody moving forward together - so they work with people from other parts of the company in good faith, and this makes it possible to keep the administrative crap (which no one likes, it's not just them) as light as possible for as long as possible.

PhantomGremlin• 10 years ago

This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month

A comment in the article made a similar point. QFT:

   I dare say you wouldn't win much work though
   turning up to pitch to potential customers and
   declaring that you'll definitely deliver
   something, but you don't know how long it will
   take or how much it will cost.

Every employee needs to be aware of time, of deadlines, and needs to understand that the money to pay their salaries needs to come from somewhere. Or they need to find a job working for some government agency, or in academia, not in the real world.

mobiuscog2• 10 years ago

If businesses didn't make promises before they knew if they could keep them, the deadlines wouldn't be such a problem.

If an employee agrees to a deadline, it's fine. If an employee is just told they have to complete a task within a deadline that they're weren't included in estimating, that's not the employee at fault.

UK-AL• 10 years ago

Probably been bitten by estimates being treated as deadlines issue. So he just doesn't bother.

Software estimation has been proven to be extremely hard and inaccurate in many academic studies, and yet business tends to want software developers to held to those estimates.

triplesec• 10 years ago

I think there's a middle ground here, and you're being somewhat unfair. And yes, the article writer wants a utopia that he won't often find. But his criticisms of a certain kind of company culture and bad unresponsive political management are valid

simula67• 10 years ago

This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month

Software development is about figuring out how to do something. Sometimes you can still kind of estimate how much time something will take, especially if it is some grunt work. But truly meaningful changes are unestimatable. If I told you 'I want you to make me some Japanese kuhoo kuhoo. I wont tell you what it is, what goes into making it and if it is even a real thing that can be made. Now tell me how much time it will take', how can you react to that ? I am not saying you acted this way, but I have seen managers act this way.

but if they disagree with a tiny aspect of the feature you've brought them, the deep domain knowledge you were hired for and dozens of customer visits you've done are nothing in the face of the awesome might of their computer science degree

Why not just let the developers do all these things ? We have been asking our product managers for customer visits for years. Would that be the end of the world ?

draw_down2• 10 years ago

Ha, I usually have the opposite problem (and I'm on the other side of the table). Product guys (and they're always guys) telling me to design the thing they want me to ship, because they suck at making decisions and want someone else to do it. (Of course they phrase it differently.)

No dice, it's my job to build the thing and your job to decide what the thing is.

Lawtonfogle3• 10 years ago

This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month,

I don't mind giving people an estimate if they know what the word means.

humanrebar3• 10 years ago

Absolutely, sow an estimate, reap a commitment, get plowed by a deadline.

z3t4• 10 years ago

because it's going to take you several hours to persuade them that you do in fact know how to do your job

Never, ever argue about the person! When arguing with programmers you should only argue about the technical side. For them it's not about prestige, it's about making a perfect system.

  X+Y=3 because I know math (wrong)
  X+Y=3 because X=1 and Y=2 (right)

mikekchar• 10 years ago

The "Heisenberg Developer" name is really excellent. I recall DeMarco saying in his excellent books (so many years ago): Do not measure anything unless you have a very specific action you want to take based on the data. Why? Because every measurement alters the way programmers work. The author reports that increasing the granularity of the work (and thereby decreasing the time between measurable status updates) led to a lack of refactoring. I have also experienced this one and it led to much head scratching on my part.

Which is not to say that one should not measure. I've never actually used Jira, but apart from that, many of the things the author talks about are generally good ideas: reduce story size to a day or so, prioritise every 2 weeks, measure delivery at about the same interval. Don't throw the baby out with the bath water.

I can say with some confidence that where they went wrong was that they tried to estimate the stories and then they made the cardinal sin of trying to measure the elapsed time for each story. In the first case, you don't need estimates. Each story is a day or so. It's enough granularity. In the case of measuring, there is no organisational benefit. You can see the average throughput of stories. You can estimate your final delivery (especially if you use a defect growth model to estimate how many requirements you are currently missing before delivery). Measuring the actual time of an individual story adds absolutely nothing to your control of the project.

The main argument that I've heard for measuring are two fold. First they feel that measurement will allow people to get better at estimating. Again, it is not needed. If you have a granularity of a day or two in your story sizes (and your throughput is showing that you are achieving that), then you have nothing to improve. If your throughput is not there, then you need to see what the problem is. It will be one of 3 things: your stories are too big, your code is too complicated, your programmers are crap. The first is solved by making your stories smaller, the second is solved by working on technical debt, the third is solved by firing your programmers. I recommend doing everything you can to solve the first, move on to the second, and only then resorting to the third.

What measuring will give you is an idea of the variance in the story sizes. This is unimportant. In fact it is critical not to measure this. All you care about is throughput. Variance is where the developers are putting the extra effort in to improve your throughput (by dealing with technical debt, improving tests in critical areas, creating efficient build systems, writing documentation, etc.). If you remove the variance (as described by the author), you destroy the ability for the developers to optimize throughput.

The second argument for measuring time is to identify stories that are (or were) in trouble. Again, this is unnecessary. First, if you have a story and you are having a hard enough time that it is taking you longer than a day or two, then you already know about it. Asking for help is what stand up is for (and really, I hate to have to say this, but that's all standup is for).

If you are not having trouble, but you are spending a few extra days to refactor something, then you already know about it. Everyone else does too because they can see the code that you refactored.

If you are sitting on your ass and wasting your days writing extremely long posts on HN, then you already know about it. And so does everyone else (because you haven't written any code today, and it's not like you asked for help...).

I'm just going to write this one time. If your reasons for measuring the amount of time for stories is because you secretly think that your developers are crap and that they don't know what they are doing, no amount of measurement is going to solve the problem. Make a decision. Fire them, or not. You can't make a crap programmer good by pointing out how much time they spent on a story. They already know it.

amag3• 10 years ago

(and really, I hate to have to say this, but that's all standup is for)

Hehe, this earned a +1 from me. I've had standups where the scrum master (who also was a lead developer) spent the first 15 minutes talking about what he did the day before.

ArkyBeagle• 10 years ago

There's no "Heisenberg" here - the company decided to do the moral equivalent of invading Russia in the winter. I quote - "Then came that requirement. The one where you try to replace an expert user’s years of experience and intuition with software."

The only problem with "finely grained management" is that it costs too much.

partycoder9• 10 years ago

About processes: You add a process when you want repeatable results. Adding blocking, synchronous steps involving people slows things down. Adding non-blocking, asynchronous, tool assisted steps are less intrusive in people's work.

About hierarchies: You add hierarchies in your organization when your quorum involves too many people and things slow down. Hierarchies exist to make consensus building simpler at the cost of representing fewer people and all the associated consequences. Hierarchy must not be abused. People need to be respectful towards others regardless of hierarchy. Each contributor is important.

About quality and technical debt: If you are always reacting to defects, you lost control of your product. You can no longer plan because you are too busy reacting to ad-hoc unplanned work. This is unprefessional and unnecessary. Keep things under control by being preventive, proactive and professional. If someone tries to convince you that non-functional requirements cannot be sold, remember that person that person to focus on functional requirements and leave the non-functional requirements to the engineers.

jondubois• 10 years ago

I've worked for companies like this. What's hilarious is that most of the employees at these companies take the process very seriously (they obviously don't know better). I've worked at both startups and big companies - I find that fine-grained management in big companies is extremely inefficient. In software, the more constraints you add to a project, the slower things will progress.

It gives non-technical managers extra visibility at the cost of speed and agility.

I can't help but chuckle to myself whenever we have a 'retrospective meeting' - Every single time, it's the same problems that come up over and over again (related to management/communication issues) and these problems never get fixed.

What's even funnier is that the closer we get to a deadline, the more meetings we have - And the more it slows us down.

There is a fundamental problem with having very fine-grained cards/stories/tasks; often, related tasks are assigned to different people but it would have been much more efficient to assign all these tasks to a single person.

yetihehe• 10 years ago

It gives non-technical managers extra visibility at the cost of speed and agility.

Hmm, just like with tracing. The more finegrained tracing, the more resources are used for communicating what you do and less resources are going into actual doing. Developers understand this, managmenet may not. Management IS about communicating, so they try to "Do Something" and enforce more communication.

dev360• 10 years ago

>> It gives non-technical managers extra visibility at the cost of speed and agility.

Keen observation. Often times these situations are just self-inflicted wounds on the part of devs too. I have worked with many devs that have had a habit of keeping stakeholders and coworkers in the dark just because they feel like they are too important to be bothered/be held accountable.

I know what I'm in for if a project management or glass house CIO is all of the sudden needed, so my top priority is always to primarily earn the trust of business stakeholders and to be as honest as possible.

taylodl2• 10 years ago

Ever work with an engineering team? Building new weapons systems? Fighter planes and the like? Just as creative an endeavor if not more so than software development yet they have schedules and budgets to meet too. And yet people's lives depend on the result. Software development can learn a lot from other engineering disciplines.

seivan4• 10 years ago

I feel like you might have missed the point. Also you're assuming these engineering teams for weapons systems and fighter planes are successful by default.

F-35?

taylodl2• 10 years ago

Not all engineering projects are successful either. What I'm saying is there's a lot of similarities between these disciplines and so there exists a large body of knowledge and experience from which we can cull and learn.

FLUX-YOU• 10 years ago

Software dev isn't driving this, business is. NASA coding practices prove we can do exactly what you're saying, but businesses don't care for (or don't often need) the rigor that NASA requires. I'd bet a lot of people would enjoy participating in NASA-quality projects if only to experience it and feel good about producing rock-solid code even if they only commit 50 lines total, but they are very rare.

vfc12• 10 years ago

This is one of the best posts on software development I've read in many years. Each sentence rings true and is an amazing read.

Its like the author is describing many of the projects I've worked before.

Micromanagement and software factories are the death of software development.

But then no matter how much I dislike these management methods, I can see why they are put in place.

There are certain developers that get to a project and just start rewriting everything with no good reason, introducing new cutting edge tools and frameworks for the fun of it and for pure CV driven development.

They introduce huge bugs close to release dates, breaking browser support, refusing to test on IE.

Lets face it, loose canons exist on all teams and we've all seen it before.

This is OK and necessary in the early development cycle, but when things get to production its different. One day something gets seriously broken, and management comes in putting in JIRA or equivalent, and micromanagement starts.

Demotivation of the early developers sets in, the ones who knew how to setup an architecture and make technical decisions. The leave and are replaced by other developers that don't necessarily could take those decisions.

The project entered a pure maintenance phase, where business as sort of given up asking too many features, it just costs too much and the results are less than ideal.

The project enters the keep it running final phase, where noone knows how certain parts of the system work anymore, all original developers long gone. Here the goal is to touch the code as least as possible and its no longer a development job, its mostly technical analysis and troubleshooting of test environments.

Then 5 or 7 years have gone through, and the business decides to replace the system with a new one and the cycle starts again.

The only way i've found to deal with this, is to become a contractor and work mostly on early to mid phases of projects. When the project enters pure maintenance I wait for a few months and then look for a new project.

iamthepieman• 10 years ago

This is similar to an experience I had. Me and the small dev team were being micromanaged. But we were getting lots of new customers for version 2.0 of our main software product and specifically targetting feature relases to snag certain customers, I feel like it worked from a business perspective.

We didn't have time to refactor, didn't have time to anticipate how something would be used in the future and build extensibility into it and the number of hacks in the codebase grew daily.

most of us on the dev team knew it was going to be a complete disaster at some point. It was going to take a week to fix a simple bug because it's copy-pasted in 7 different places and something derivative now relied on the bugs behavior.

But we were releasing fast and getting money because of it. Initially we fought it but eventually I just figured that if I wasn't on another project when it came time to pay the piper then I'd just find another job.

I had given my warnings - when I did have time I still tried to do things right and refactor old code. Ultimately though, the business tradeoff decisions weren't mine to make and I wasn't going to lose any sleep over it.

rocky1138• 10 years ago

This post should be pinned to the top of Hacker News.

draw_down2• 10 years ago

I say it's a mistake to expect to have creative control at all, over something owned by the corporation you work for. Best to accept that it's not your baby you're working on. You don't get the profits or the glory or any of that. Just do your tasks and treat it like what it is: a job.

Creative control and passion and all that is for side projects and things you build yourself. I just feel it's setting yourself up for disappointment to think otherwise. Companies are not founded to provide the ideal environment for software development. They are founded to make products and hopefully a profit.

You might argue that a smart business person would provide that environment in order to get their product built, and maybe you'd be right, but that also risks building the thing developers want to build as opposed to what could sell. And as soon as you intervene, poof goes the ideal environment. So even if the environment exists at a company, as at the beginning of this story, it's best understood as a happy accident and shouldn't be expected to last.

kolbe• 10 years ago

Work long enough and with many different companies, and you will inevitably have had an experience much like this one. And it's not just in software. Any profession that relies on some form of engineering knows what this is like. There's a reason why Dilbert is so funny.

Heisenberg Developers (2014)

Related Stories