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

71–80 of 193 posts

Re: Heisenberg Developers (2014)

#71

Post by tajen »

CryoLogic wrote: post #28
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…

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

Young engineer, I tried being entrepreneurial. I confirm team leads don't like it, even if the company displays the marketing you describe. Better become more skilled in your field than just overly motivated. It's sad that we only understand that after a few years in the job.

Re: Heisenberg Developers (2014)

#72

Post by lentil_soup »

CryoLogic wrote: post #28
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…

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

Is HR the first line of contact when applying in most companies? Where I work I think we (the developers) get all the resumes that come in and decide to decline or continue the process, HR only handles the logistics

Re: Heisenberg Developers (2014)

#73

Post by Joeri »

abalone wrote: post #21

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

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.

Re: Heisenberg Developers (2014)

#74

Post by bb88 »

Ace17 wrote: post #54
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 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 killin…

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

Re: Heisenberg Developers (2014)

#75

Post by gknoy »

donatj wrote: post #45
twunde wrote: post #41

Earlier quoted context omitted.

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…

git bisect + git blame I find usually more useful than verbose likely partially correct notes.

That often tells What changed, but rarely does it seem to tell Why. When the logic changes (and tests too) because the sales team now needs Different Things, it's very useful to have a ticket.

Re: Heisenberg Developers (2014)

#76

Post by jondubois »

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.

Re: Heisenberg Developers (2014)

#77

Post by UK-AL »

gyardley wrote: post #42

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

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.

Re: Heisenberg Developers (2014)

#78

Post by rglullis »

bsandert wrote: post #27
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. 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.…

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

Re: Heisenberg Developers (2014)

#79

Post by yetihehe »

jondubois wrote: post #76

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…

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

Re: Heisenberg Developers (2014)

#80

Post by abalone »

Joeri wrote: post #73
abalone wrote: post #21

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

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

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.

Post reply on HN