Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Heisenberg Developers (2014)

mikehadlow.blogspot.cl

Post reply on HN
Print view View original

61–70 of 193 posts

Re: Heisenberg Developers (2014)

#61

Post by rorykoehler »

chime wrote: post #49
rorykoehler wrote: post #24

Earlier quoted context omitted.

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…

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…

I appreciate your perspective however right now, due to personal circumstances/ bureaucratic reasons, I need a full-time job. I have run my own businesses previously and enjoyed it immensely however they also burnt me out. I learnt a lot from this that I will take with me. My experiences since then have made me realise I should apply the approach from your 1st paragraph more in future.

Re: Heisenberg Developers (2014)

#62

Post by clockwerx »

donatj wrote: post #2

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'…

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.

Re: Heisenberg Developers (2014)

#63

Post by bb88 »

YZF wrote: post #9

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…

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

Re: Heisenberg Developers (2014)

#64

Post by johnsonjo »

vinceguidry wrote: post #30
hartator wrote: post #26

Earlier quoted context omitted.

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.

Re: Heisenberg Developers (2014)

#65

Post by bb88 »

twunde wrote: post #41
badminton1 wrote: post #20

Earlier quoted context omitted.

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.

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 tit…

That really assumes that

1) Tickets are detailed enough and have been for a long enough period of time.

2) The functionality that's to blame was implemented in one ticket.

Unfortunately, that's almost never true anymore for anyone.

Re: Heisenberg Developers (2014)

#66

Post by skewart »

vinceguidry wrote: post #11

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 wi…

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

Re: Heisenberg Developers (2014)

#67

Post by bbcbasic »

vinceguidry wrote: post #30
hartator wrote: post #26

Earlier quoted context omitted.

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'm guessing you're new in this trade.

Re: Heisenberg Developers (2014)

#68

Post by skewart »

vinceguidry wrote: post #33
bsandert wrote: post #27

Earlier quoted context omitted.

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

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.

Re: Heisenberg Developers (2014)

#69

Post by cousin_it »

vinceguidry wrote: post #11

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 wi…

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.

Re: Heisenberg Developers (2014)

#70

Post by bb88 »

majewsky wrote: post #56
kasey_junk wrote: post #29

Earlier quoted context omitted.

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.

This touches on the classic question of "is coding engineering or art"? If it were engineering, it would become quantifiable once we have enough empirical data from previous projects to base our theories on. If it were art, that would be impossible since every project is as individual as the last one. It's probably inbetween.

Engineering is just applied science. And other engineering fields experience the same types of failure that software engineering experiences -- cost overruns, undefined requirements, unseen technical hurdles, etc.
Post reply on HN