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

51–60 of 193 posts

Re: Heisenberg Developers (2014)

#51

Post by golergka »

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…

Don't work in a company with the people who told you that. It's not only wrong, it's bad for business, and I constantly see the negative consequences of this worldview.

Re: Heisenberg Developers (2014)

#52

Post by CryoLogic »

rorykoehler wrote: post #37
CryoLogic wrote: post #28

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…

Interesting. Perhaps something I can learn from. What kind of companies have you worked for (large corps / startups / SMEs?) and what kind of work do you do for them (any specialisations)? How do these experiences contrast to your pre-employment/self-employment experiences?

I do full-stack development. Front-end, back-end, some server admin, DB, UX, SEO, etc.

I worked at a F500 building tools to visualize big data and had a great time. Learned a lot and had a lot of freedom.

Afterwards, a VC funded startup - didn't really fit in, most of my co-workers where hardcore academics and it had a lot of micromanaging.

Also did some contract gigs, subcontracting for another company which could be good, bad or neutral (all depends on the client).

Self-employement is awesome, because you get to explore a ton of new things. You get to learn about SEO, business models, cutting costs to increase profits, increasing conversions, brand image, UX, etc. You also get to know your audience really well.

In my case, the biggest downside is I could never build a strong network because most of my revenue was coming from ads and donations and the target audience was younger.

It's easier to network when you are out and about, and always working with people who have their own networks.

I'd love to start a company (on a bigger scale) some day, when I have a stronger network, a larger skillset, and some capital so I can make sure I am feeding myself every week :)

Re: Heisenberg Developers (2014)

#53

Post by ArkyBeagle »

There's no "Heisenberg" here - the company decided to do the moral equivalent of invading Russia in the winter. I quote - "Then came that requirement. The one where you try to replace an expert user’s years of experience and intuition with software."

The only problem with "finely grained management" is that it costs too much.

Re: Heisenberg Developers (2014)

#54

Post by Ace17 »

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 killing their creativity?

Re: Heisenberg Developers (2014)

#55

Post by PhantomGremlin »

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

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 be aware of time, of deadlines, and needs to understand that the money to pay their salaries needs to come from somewhere. Or they need to find a job working for some government agency, or in academia, not in the real world.

Re: Heisenberg Developers (2014)

#56

Post by majewsky »

kasey_junk wrote: post #29
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.

But compared to what? Most software continues to be bespoke/new work. If a different team/process was used would we have been as successful/spent as much money.

This touches on the classic question of "is coding engineering or art"? If it were engineering, it would become quantifiable once we have enough empirical data from previous projects to base our theories on. If it were art, that would be impossible since every project is as individual as the last one. It's probably inbetween.

Re: Heisenberg Developers (2014)

#57

Post by fsloth »

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 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 productive, but a much more predictable form of management.

The problem was not the Jira. It was the new PM who instituted the cultural change. Jira can be used just a well to document work done by intrinsic motivators.

Re: Heisenberg Developers (2014)

#58

Post by badminton1 »

About processes: You add a process when you want repeatable results. Adding blocking, synchronous steps involving people slows things down. Adding non-blocking, asynchronous, tool assisted steps are less intrusive in people's work.

About hierarchies: You add hierarchies in your organization when your quorum involves too many people and things slow down. Hierarchies exist to make consensus building simpler at the cost of representing fewer people and all the associated consequences. Hierarchy must not be abused. People need to be respectful towards others regardless of hierarchy. Each contributor is important.

About quality and technical debt: If you are always reacting to defects, you lost control of your product. You can no longer plan because you are too busy reacting to ad-hoc unplanned work. This is unprefessional and unnecessary. Keep things under control by being preventive, proactive and professional. If someone tries to convince you that non-functional requirements cannot be sold, remember that person that person to focus on functional requirements and leave the non-functional requirements to the engineers.

Re: Heisenberg Developers (2014)

#59

Post by badminton1 »

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 doesn't scale to large or multiple teams.

Re: Heisenberg Developers (2014)

#60

Post by badminton1 »

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.

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