Live data from Hacker News

Doing too much work on one's own before looping in others

thezbook.com

241–250 of 395 posts

Re: Doing too much work on one's own before looping in others

#241

Earlier quoted context omitted.

> It also offers chance to produce memorable work as nobody remembers the set of 3 point tasks you completed ten sprints ago. This is one of the more toxic ones. To get past senior, you often need to be seen to do Big Memorable Things. It sometimes leads to perverse incentives.

I think it's management and their "agile" philosophy that's toxic here, intentionally depriving engineers of any sense of ownership, autonomy, or vision-fulfillment over their work by constantly bouncing them around across small disjoint tasks. I am incredibly fortunate to work in a place that values ownership, both explicitly and in practice. Given how widespread the opposing value system is, I'm afraid to ever leav…

because programmers must be replaceable parts for the industry to keep going at status quo

Re: Doing too much work on one's own before looping in others

#242
I think I do this because it is more fun. Involving lots of other people, especially non-engineers, really can suck the fun out of programming for me. I'm not antisocial - I love to discuss what I'm doing and bounce ideas around with other IC engineers. But PM/management incentives are generally aligned towards viewing exploratory work as a waste of time; it might be, but it's what makes programming fun, so if I don't get to do it, I will kind of just consider quitting. Of course, there are times for exploration and times for execution, but to be happy at work, I think most people need to have (and deserve) a mix.

I'm sure the PM and engineering lead and the company in general would prefer that I produce small deliverables on a frequent cadence, for a variety of reasons: (1) to make sure I'm doing work and not goofing off, (2) to provide better visibility to higher-ups about progress towards an ultimate goal, (3) to encourage me to prioritize delivering finished products over say personal learning, work-life balance, etc.

I hope I don't sound too rabidly anti-work, but when I look for jobs, I pretty much prioritize the autonomy that management will give me over most other factors; nothing really sucks the joy out of programming quite like being told to break your work into "smaller tasks" so the burndown chart is prettier.

Re: Doing too much work on one's own before looping in others

#243

Earlier quoted context omitted.

A lot. Technical managers need not be experienced technical talents who have made a potentially incompatible shift to management.

It is better if the managers of technical people are technical themselves. Otherwise you wind up with the Dilbert "pointy-haired-boss" syndrome. The non-technical manager is extremely easy to bullshit, so it's better for the company in almost all ways.

The problem with the "non-technical manager = easy to bullshit" idea is that it's basically the engineer's equivalent of the "engineer = assembly line cog who shouldn't be exposed to anything but their JIRA tickets" idea for bad management. It's what you find in poorly-run or excessively cheap organizations, but it's hardly an upper bound.

Re: Doing too much work on one's own before looping in others

#244

Earlier quoted context omitted.

> Lawyers must hate their work. A friend of mine is a criminal defence lawyer. I get the impression he really enjoys his work – he gets to meet a lot of people he never normally would (bikie gang members, terrorists, murderers, drug dealers, drug addicts, etc) – and he feels safe in doing so (he tells me that defendants trying to harm their own lawyers is quite rare, rare enough that he isn't worried about it). Once,…

I think criminal defense is a great service to humanity. It's hard to estimate how many are wrongfully accused, but surely there are many. Further, things like the plea bargain system or parole regularly lead innocent people to proclaim their guilt. It's very messed up and must be a terrible trauma for some. Lastly, I think even guilty people deserve humane treatment and perhaps forgiveness.

> and perhaps forgiveness.

I would agree here, on the condition of rehabilitation.

Obviously our "justice system", isn't.

Edit: Speaking of the US above, no experience or knowledge about other countries systems. It appears I've found a new gap in my knowledge, anyone have a good intro to how courts work in their country?

Re: Doing too much work on one's own before looping in others

#245

Earlier quoted context omitted.

> If your work is bullshot, I bill tighter than my lawyer Lawyers must hate their work.

> Lawyers must hate their work. A friend of mine is a criminal defence lawyer. I get the impression he really enjoys his work – he gets to meet a lot of people he never normally would (bikie gang members, terrorists, murderers, drug dealers, drug addicts, etc) – and he feels safe in doing so (he tells me that defendants trying to harm their own lawyers is quite rare, rare enough that he isn't worried about it). Once,…

I have a theory that lawyers in many ways are not unlike a security engineer:

you get the satisfaction of exploiting the system, bending the rules to your advantage, making the impossible work. and when you’re good at your job, you get paid well ( lawyer by many more times of course )

case n point: defending OJ

Re: Doing too much work on one's own before looping in others

#246

Earlier quoted context omitted.

I think it's management and their "agile" philosophy that's toxic here, intentionally depriving engineers of any sense of ownership, autonomy, or vision-fulfillment over their work by constantly bouncing them around across small disjoint tasks. I am incredibly fortunate to work in a place that values ownership, both explicitly and in practice. Given how widespread the opposing value system is, I'm afraid to ever leav…

because programmers must be replaceable parts for the industry to keep going at status quo

We have plenty of turnover and it works out fine. In fact turnover of the senior engineers who are service/project owners usually creates the opening for one of the more junior contributors to demonstrate L+1 competency by taking over.

Re: Doing too much work on one's own before looping in others

#247

Earlier quoted context omitted.

I wholeheartedly agree, if you need daily feedback you're a bad manager (unless you're in some exotic situation like a rocket launch or something). This issue largely disappears if your engineers are given the proper context, background and system overview. I'm not advocating everybody should take their project and run with it for weeks on end, but daily updates are ridiculous.

I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to…

I hope this is comment is made in irony.

Re: Doing too much work on one's own before looping in others

#248

Earlier quoted context omitted.

Not all development fits nicely into day-or-two chunks. Forcing all your work to fit nicely into this type of mold is an arbitrary restriction that serves no real purpose except to check all the necessary scrum boxes, give the illusion of extra productivity, and allow for micro-management. It ends up being completely antithetical to thinking deeply and long term about the the code you're writing. I've worked on teams…

What do you think of the idea that providing finished work on an every-day-or-two cadence allows you to collect feedback from your customers in a way that keeps your work focused and relevant to their needs?

You can gather plenty of useful feedback to keep your work focused and relevant on cadences other than one or two days. What kind of customer even wants to provide feedback that often? That sounds awful, not to mention being a poor user experience, where users are treated like beta testers, with half baked features constantly pushed out the door.

This also ignores the fact that there is a huge amount of important work that is effectively invisible to the end user, but is absolutely crucial. The workflow you're suggesting disincentives the team from working on those things, and may even punish them for it (as they are not shipping customer visible features).

Re: Doing too much work on one's own before looping in others

#249

Earlier quoted context omitted.

I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to…

I think most people are salty about your comment because they fail to see the subtle difference between: 1) "Everyday you should ship something" 2) "At the end of each day you should be able to tell your line manager in a clear and concise way exactly what you did; if you can't you've done nothing." 2) does not mean ship code: you could have spent 12 hours thinking and reading code. But if you can explain i.e provide…

Or you can hire good developers who value their work and want to ship high quality software, and get out of their way so they can get things done. Your method seems to be treating your developers like children who will refuse to get work done if somebody isn't watching over their shoulder. If that's happening, then I think you have a hiring problem.

Re: Doing too much work on one's own before looping in others

#250

I'm the author of the post - would love any feedback / similar experiences / contrasting opinions!

I can’t load the page due to a redirect loop: it does a 301 redirect to the same URL. Observed from Australia, in Firefox, curl and Chromium, all under Linux, talking to 66.235.200.155.
Post reply on HN