Live data from Hacker News

Heisenberg Developers (2014)

mikehadlow.blogspot.cl

141–150 of 193 posts

Re: Heisenberg Developers (2014)

#141

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…

I had a similar background--worked my way through school doing small to medium size freelance projects. Much of my freelance work was contracting for one company (where I was mentored by one the senior developers) and few startups, so it wasn't quite as bad as what you experienced. Some employers think you're not "office material" if you happened to be a hard-working, independent worker that managed to pay their way through school while learning on the job. I assume I probably dodged a bullet working at any of those places, if that's the way they hire.

After graduation, I had a few tell companies me that my work during school as sort of a "black mark" and I think it's sort of humorous looking back at it now. Currently, I'm the technical lead for my dev team and the contract work I did while in school is probably the best experience I had for the work I do now. Gave me a broad range of experience that reinforced the theory and concepts I was learning while in school.

Re: Heisenberg Developers (2014)

#142
post #135

Earlier quoted context omitted.

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

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

This would be a good analogy if the guy didn't know he worked for a tech company.

Re: Heisenberg Developers (2014)

#143
post #105

Earlier quoted context omitted.

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

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.

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

Exactly!

Re: Heisenberg Developers (2014)

#144

Earlier quoted context omitted.

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

You are assuming that staying 8 hours a day in a job you don't care about is less consuming than staying those 8 hours in a job you love. I can't even imagine where did you get that from. One will cause deep depression and burnout in no time - the other is a wonderful life experience.

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

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

Re: Heisenberg Developers (2014)

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

Re: Heisenberg Developers (2014)

#146

Earlier quoted context omitted.

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

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

> "The programmer, like the poet, works only slightly removed from pure thought-stuff."

I don't agree with this. Programming does not start from scratch. You are always building on someone else's work. Sure, there's the hardware and software you're building on top of, but there's also methodologies and philosophies that other people came up with that you're using too, even if it's only subconscious. It's not the same all-encompassing mental marathon that writing good poetry is. Or, at least, it doesn't have to be.

My work quality went up when I stopped caring about things I really shouldn't have been caring about. I now feel that the biggest source of problems in codebases comes not from so-called technical debt, but from programmers incessantly biting off more than they can chew.

Re: Heisenberg Developers (2014)

#147

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.

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

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.

Re: Heisenberg Developers (2014)

#148
post #135

Earlier quoted context omitted.

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

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.

Re: Heisenberg Developers (2014)

#149

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 mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about." wat

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

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

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

Re: Heisenberg Developers (2014)

#150

Earlier quoted context omitted.

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

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.

Post reply on HN