Live data from Hacker News

Heisenberg Developers (2014)

mikehadlow.blogspot.cl

81–90 of 193 posts

Re: Heisenberg Developers (2014)

#81

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 envy you. Mostly being a programmer learning "new" things is the same as a taxi driver moving to a different city every half year and learn the new topology.

In both cases, you're not learning anything that is fundamental to human knowledge.

Re: Heisenberg Developers (2014)

#82
post #57

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

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.

Re: Heisenberg Developers (2014)

#83

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…

That's odd. We get excited when we see an entrepreneurial profile like yours. We have several developers who want to start companies and actually try to help them along that path.

The benefit to a motivated engineer is you can give them problems to solve instead of specs. The outcome or results can be less predictable but can also be much more effective.

Re: Heisenberg Developers (2014)

#84

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

Re: Heisenberg Developers (2014)

#85
post #83

Earlier quoted context omitted.

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…

That's odd. We get excited when we see an entrepreneurial profile like yours. We have several developers who want to start companies and actually try to help them along that path. The benefit to a motivated engineer is you can give them problems to solve instead of specs. The outcome or results can be less predictable but can also be much more effective.

How do you feel about the potential for high turnover with entrepreneurial types, as it seems the general consensus is they will inevitably leave to start their own thing? How long do you expect someone to work for you before hiring them, getting them up to speed with your system, and integrating them into the company is a worthwhile investment?

Re: Heisenberg Developers (2014)

#86

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…

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.

Re: Heisenberg Developers (2014)

#87

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.

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.

Re: Heisenberg Developers (2014)

#88
post #80
post #73

Earlier quoted context omitted.

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.

I would, and have, argue that estimates and time tracking are, in general, wasted effort.

If you have good priorities, estimates are irrelevant, because you'll be working on the most important things, and that is unlikely to change no matter the estimated effort. If you don't have estimates, then you don't need time tracking to see if your estimates are correct.

You've just eliminated half of the overhead for software development - the only added cost is that you must continually understand and update your priorities (or values, if you prefer), which you should be doing anyway.

Re: Heisenberg Developers (2014)

#89

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…

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.

Re: Heisenberg Developers (2014)

#90

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…

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
Post reply on HN