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

151–160 of 193 posts

Re: Heisenberg Developers (2014)

#151

Post by Lawtonfogle »

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…

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

Re: Heisenberg Developers (2014)

#152

Post by __jal »

rorykoehler wrote: post #24
CryoLogic wrote: post #4

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

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…

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.

Re: Heisenberg Developers (2014)

#153

Post by kasey_junk »

badminton1 wrote: post #150
kasey_junk wrote: post #147

Earlier quoted context omitted.

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.

"why you build software" = requirement. end-user/customer/client happiness = Customer satisfaction surveys and ratings help you acquiring it. Basic KPIs such as retention rates and engagement can also help you understand this. A/B testing helps the process of testing assumptions in a data driven way.

That is a definition of requirement that is different than what most of the industry uses. Most of the industry sees requirements as "how the software should behave". Even with your new definition, I've seen little evidence that we have mature processes around collecting requirements.

As for surveys, KPIs, A/B testing etc. Those are neither standardized, proven to be valuable in a rigorous way, nor widely used. All signs of an immature industry. Further, they can only be used in software development processes that allow for iterative deployment.

Re: Heisenberg Developers (2014)

#154

Post by badminton1 »

gearoidoc wrote: post #16
kasey_junk wrote: post #10

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.

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.

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

Re: Heisenberg Developers (2014)

#155

Post by throwawaymsft »

Lawtonfogle wrote: post #148
throwawaymsft wrote: post #140

Earlier quoted context omitted.

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

Well it isn't. Officially it is a republic. A democratic one, but a republic. Unofficially political power is so unevenly distributed it should be called an oligarchy. Officially, North Korea is also a republic. Now, if the person thought the President was a king of a monarchy, then I would say they have been listening to too much talk radio.

Originally I was going to say "democratic republic" but then it becomes a game of minutia. Not knowing that Amazon is controlled by a board of directors (elected by shareholders, the owners) is just like not realizing the president is elected and we don't have King Obama.

Re: Heisenberg Developers (2014)

#156

Post by gearoidoc »

mobiuscog wrote: post #84
PhantomGremlin wrote: post #55

Earlier quoted context omitted.

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…

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.

Thats not what gyardley is saying though. He's talking about developers who refuse to estimate how long a chunk of work will take.

Re: Heisenberg Developers (2014)

#157

Post by gearoidoc »

badminton1 wrote: post #154
gearoidoc wrote: post #16

Earlier quoted context omitted.

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.

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

"just because they were born"

Thats an example of a successful pregnancy project.

Re: Heisenberg Developers (2014)

#158

Post by JanneVee »

vinceguidry wrote: post #110
JanneVee wrote: post #86

Earlier quoted context omitted.

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

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

Re: Heisenberg Developers (2014)

#159

Post by humanrebar »

vinceguidry wrote: post #116
bb88 wrote: post #74

Earlier quoted context omitted.

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

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

Re: Heisenberg Developers (2014)

#160

Post by humanrebar »

Lawtonfogle wrote: post #151
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…

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

Absolutely, sow an estimate, reap a commitment, get plowed by a deadline.
Post reply on HN