Live data from Hacker News

Heisenberg Developers (2014)

mikehadlow.blogspot.cl

181–190 of 193 posts

Re: Heisenberg Developers (2014)

#181
post #179

Earlier quoted context omitted.

> why I think you're getting so much opposition Getting plenty of upvotes too. If I find I'm not controversial enough, I'll dig around for something more interesting to say. > you are suggesting we should be satisfied simply being programmers I'm doing nothing of the sort. What I'm saying is that you shouldn't let your job become your identity. Dream big, but realize that the best company to be the receptacle for tho…

Thanks for your clarifying where you're coming from. I read comments like > All good things eventually come to an end, and you need to be ready for the inevitable. > 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. > You're still getting paid the same, but are having your responsibilities taken away. Most other people are overworked an…

I'm not interested in resonating. I want to challenge people's beliefs. I don't care for platitudes. I want to dive down into the subtleties and tease out complex truths.

I don't think the professional world sucks. I think it's awesome. I spent much of my twenties doing construction work. That world sucks. The professional world sucks only so long as you lack professionalism.

Once you learn professionalism then the professional world stops being able to hold you. I have been Office Space-ing my work life down to where I can do pretty much whatever I want with my work time.

I have been cultivating business contacts for some time now, creating a network of clients so that I can make my jump into the business world. The professionalism you learn in corporate jobs is invaluable there.

Every day brings with it a more relaxed approach, more return on my efforts, more ease in learning new things.

Developers are missing out on the unique opportunities that the professional world offers by focusing on non-issues like whether their bosses will allow them to pay down technical debt. How utterly silly from my perspective! If it's that important to you, just man up and do it, damn the consequences!

Re: Heisenberg Developers (2014)

#182

Earlier quoted context omitted.

> You can't have it both ways. Sure you can. They paid for the codebase, it's theirs. You don't own it, whether you have the responsibility for keeping it maintained or not. That's true no matter which approach the company takes to managing their technical infrastructure. They can make decisions about it with or without your input and there's absolutely nothing wrong with that. It's theirs, not yours. What you own is…

> You do not bring these up to your employer or allow him to stop you from doing them, because they're part of the job. I agree with that. Don't need to discuss how sausage is made. OP was pointing out that there are circumstances where the sausage making is micromanaged, which puts a kink in this plan.

Wouldn't put a kink in mine. I'd just carry on as usual. When I write code, I don't release it until it's been cleaned and refactored to my satisfaction. If a micromanaging boss wants to know my progress, the answer is simple. It's not done. He wants to know why, I'll tell him. I'm not happy with X class and I'm cleaning up the methods and reorganizing it. Should only take another hour.

If he starts getting 1984 on me and demanding I cut it short and deploy, then it's time for a closed-door meeting. He might be my boss, but he's not telling me how to do my job.

Re: Heisenberg Developers (2014)

#183

Earlier quoted context omitted.

> You do not bring these up to your employer or allow him to stop you from doing them, because they're part of the job. I agree with that. Don't need to discuss how sausage is made. OP was pointing out that there are circumstances where the sausage making is micromanaged, which puts a kink in this plan.

Wouldn't put a kink in mine. I'd just carry on as usual. When I write code, I don't release it until it's been cleaned and refactored to my satisfaction. If a micromanaging boss wants to know my progress, the answer is simple. It's not done. He wants to know why, I'll tell him. I'm not happy with X class and I'm cleaning up the methods and reorganizing it. Should only take another hour. If he starts getting 1984 on m…

> He might be my boss, but he's not telling me how to do my job

100% agree. If more developpers shared this attitude, world would be a better place!

Re: Heisenberg Developers (2014)

#184

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…

> because it's going to take you several hours to persuade them that you do in fact know how to do your job

Never, ever argue about the person! When arguing with programmers you should only argue about the technical side. For them it's not about prestige, it's about making a perfect system.

  X+Y=3 because I know math (wrong)
  X+Y=3 because X=1 and Y=2 (right)

Re: Heisenberg Developers (2014)

#185

Earlier quoted context omitted.

When I get asked this in an interview, I always answer the same way: yes, I will probably go to the next gig faster than other employees. But I will get up to speed faster, and I will produce more output for the business itself in the time I'll spend in your company.

This is the reality but my question was more about perception vs reality.

[deleted]

Re: Heisenberg Developers (2014)

#186

Earlier quoted context omitted.

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?

When I get asked this in an interview, I always answer the same way: yes, I will probably go to the next gig faster than other employees. But I will get up to speed faster, and I will produce more output for the business itself in the time I'll spend in your company.

When you leave, much of your knowledge about the thing you helped to build will leave with you. They want that to stick around.

Re: Heisenberg Developers (2014)

#187
post #94

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…

> 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. This is terrifying. I wouldn't be surprised if his 401(k) was 100% Amazon stock "because that's where he works" or something.

100% of what stock, didn't Bezos own everything?

Re: Heisenberg Developers (2014)

#188
post #82
post #57

Earlier quoted context omitted.

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

I've found that tracking tools are good to have even at times when I've been able to work in the manner of freedom the article describes. It's just that they are used differently, more in a way to help remember things. Things that either needs to be done or things that have been done. Especially those nightmarish things that took a long time to solve, so documenting the process is good for the future, in case it happens again.

It wasn't always like that for me (document, bah! comments, bah!) but as I grow older I've come to appreciate the possibility to offload information in my brain to a more persistent media. This way I only keep the index in my brain ("Hey, wait a minute, I recognize this..."). Maybe I'm just lazy but I hate doing the same thing twice. I also hate saying the same thing twice so before I explain something to someone I like to write it down and give them a copy. Then when they ask me about it I simply refer them to the document (in a friendly (RTFM) manner).

Re: Heisenberg Developers (2014)

#189

The "Heisenberg Developer" name is really excellent. I recall DeMarco saying in his excellent books (so many years ago): Do not measure anything unless you have a very specific action you want to take based on the data. Why? Because every measurement alters the way programmers work. The author reports that increasing the granularity of the work (and thereby decreasing the time between measurable status updates) led t…

> (and really, I hate to have to say this, but that's all standup is for)

Hehe, this earned a +1 from me. I've had standups where the scrum master (who also was a lead developer) spent the first 15 minutes talking about what he did the day before.

Re: Heisenberg Developers (2014)

#190
post #186

Earlier quoted context omitted.

When I get asked this in an interview, I always answer the same way: yes, I will probably go to the next gig faster than other employees. But I will get up to speed faster, and I will produce more output for the business itself in the time I'll spend in your company.

When you leave, much of your knowledge about the thing you helped to build will leave with you. They want that to stick around.

Then pay for it. It's pretty much that simple.
Post reply on HN