[HN Gopher] Doing too much work on one's own before looping in o...
___________________________________________________________________
Doing too much work on one's own before looping in others
Author : alokedesai
Score : 326 points
Date : 2022-01-25 17:39 UTC (5 hours ago)
(HTM) web link (thezbook.com)
(TXT) w3m dump (thezbook.com)
| zachlloyd wrote:
| working on the issue with the site going down. more traffic than
| i expected...
| mt_ wrote:
| Would you consider that a mistake most engineers make?
| elric wrote:
| Knowing when to loop in others is one of the skills that makes a
| senior engineer. Too early and you end up wasting other people's
| time. Too late and you end up wasting everyone's time. Finding
| the sweet spot is important, but it's also important to learn
| which questions to ask. It's one of those skills that I wish
| could be taught, but it seems something you have to get a feel
| for over time.
| alokedesai wrote:
| I work at Warp (https://www.warp.dev/) where Zach, the author of
| the post, is the founder.
|
| One practice we've gotten into the habit of is demoing projects
| at standup as soon as possible. I've found this has been useful
| to force myself to get to an end-to-end version of a project
| sooner. This is useful not just in derisking the technical
| implementation but also in getting product feedback sooner. By
| playing around a live demo earlier, we often find that the
| product experience needs to be refined in ways we couldn't
| validate from Figma mocks alone.
| uejfiweun wrote:
| I feel like one of the biggest antidotes to this is just a simple
| daily standup. My team does this, a daily 30 minute meeting, and
| everyone says what they're working on as well as any blockers.
| Seems to work very well in terms of course correction at an early
| point.
| jack_riminton wrote:
| I think because most people give very short descriptions in
| their standups i.e. "Working on x today, with a bit of y, no
| blockers". Perhaps due to things mentioned in the article,
| people don't want to or feel the need to invite feedback
| claylimo wrote:
| Where I work everyone will do their check-in but the
| important part is that everyone has a different personality.
| Like some people can be more confused and have a hard time
| explaining or even remembering what they did before so it's
| helpful to ask questions during their check-in to see if they
| need help. Some people might work on the same task for weeks.
| People are often afraid to ask for help. Or, maybe their task
| needs to be broken into something smaller given new
| information. The daily check-in is also a way for them to
| connect with someone else in the team who can actually help
| them. I'll tell them to either hang out at the end of standup
| or schedule a meeting with each other.
|
| Having someone leading the standup, if done correctly, can
| help hold people more accountable for what their progress is
| toward the sprint goal and remove obstacles. This is one of
| the responsibilities of a scrum master although you don't
| need to be a scrum master at all to do this.
| zachlloyd wrote:
| Right, we do a standup, but if you're not careful the updates
| can be generic enough like "making progress on X" where you
| still end up working too long without feedback
| ziggus wrote:
| Why the conflation of 'engineer' and 'developer'? That's a bit
| confusing.
| spmurrayzzz wrote:
| I'm curious, what about that semantic differentiation is
| confusing for you?
|
| At least in my experience, "Software Engineer" is a standard
| title for the kind of work the author is describing in the
| article and is often used interchangeably with "Developer".
| io98763 wrote:
| I think they mean generally. And I tend to agree. I had
| suspicions while reading it but wasn't completely sure till I
| checked the Author's bio on the right. Some, if not a lot, of
| it doesn't apply well if at all the the "classic" fields of
| engineering, where engineers tend to be much more focused and
| trained in their skills.
| gfody wrote:
| there's no classical software development engineering so
| depending where you were trained (web startup vs. software
| company vs. deep in the bowls of a huge corporation etc.)
| you could have very different ideas of normal - see eg:
| https://www.stilldrinking.org/programming-sucks
| spmurrayzzz wrote:
| This seems, at best, an anecdotal and/or an arbitrary
| distinction about what qualifies as "Engineering". Software
| engineering, as an applied discipline both in name and in
| practice, has existed since at least the mid-to-late
| 1960's. And many of the orgs in those days which adopted
| that title normatively, employed many folks who were
| "focused and trained in their skills" (e.g. NASA) and
| worked alongside of those in the more classical engineering
| domains.
|
| Speaking in my own experience, working closely with
| hardware/mechanical/electrical folks on a novel product
| line, they are exposed to a lot of the same subject matter
| covered in the article. Many of the tradeoffs explored
| there are absolutely relevant to the older engineering
| disciplines.
| jack_riminton wrote:
| This is the least interesting thing in the article. It doesn't
| matter.
| recursive wrote:
| I've never heard a difference between the two. Your confusion
| is confusing.
| sytse wrote:
| GitLab our iteration value
| https://about.gitlab.com/handbook/values/#iteration is meant to
| address exactly this problem
| kerneloftruth wrote:
| "Looping in others" is an opportunity for others to say NO, or to
| try and redirect you, or to jump (unwanted and unneeded) onto
| your band wagon. If I'm working with true peers (not age or title
| peers, but truly similar in talent and ability), then their early
| involvement or collaboration is great.
|
| Generally, however, I prefer to get solutions developed to the
| point where they are their own proof. It's much harder to argue
| against something that's (near or entirely) completed and which
| proves to work. It's fine for me to then involve others to get
| their feedback, etc.
| TameAntelope wrote:
| Proof to whom? Shouldn't you be developing things your
| customers need, not some pet project you enjoy working on for
| its own sake?
| gorgoiler wrote:
| Solid advice. Everything is such a difficult balancing act when
| you work with other engineers. I say this because at the other
| end of the spectrum its really easy to land yourself and those
| around you in needless drama by asking too publicly for feedback
| on ideas. _Hey everyone, just wondering what our thoughts as a
| team are on auto formatting the codebase / switching tabs to
| spaces / repainting the bike shed?_
|
| Some wise advice I once got from an engineer who has gone on to
| be a stellar engineering leader: utilise the power of managers.
| Good managers are drama fire breaks. They can tell you -- without
| raising the emotional stakes with anyone else -- why a particular
| bit of tech debt exists, whether anyone on their team is going to
| be amenable to you fiddling with it, and who to work with
| directly on anything likely to cause drama would it have been
| more widely shared.
|
| Managers aren't immune to drama but the good ones can help keep
| it minimised.
| emptybottle wrote:
| My experience is different in that large patch sets usually get a
| "looks good" while smaller sets get a lot of varied feedback.
|
| Depending on what your personal goals are (and your tolerance for
| accountability should things go wrong) doing the work up front
| can be a good approach.
| redisman wrote:
| I think that's just because it's too much work to review so
| people give up
| schrodera wrote:
| Going dark alone does not very often yield results - even if the
| right solution comes out getting others up to speed will remove
| any time gained before easily.
|
| Going dark as a team is a different story.
| jackblemming wrote:
| Why wasn't this caught by a million different processes that most
| teams have? Scrum, team lead, n different managers, etc. This is
| on the process, not the engineer.
| denimnerd42 wrote:
| we are probably hiding the work and not looping in those
| mentioned precisely because it gets shut down
| jackblemming wrote:
| That's understandable. The nuance here is senior engineers
| going off and doing things they know need to be done vs
| juniors getting lost in the weeds. If you're the former, and
| you're always shutdown from doing things you know are
| important, you probably need to find new employment.
| alanbernstein wrote:
| > Internal Server Error
|
| I do make that mistake quite often!
| iab wrote:
| Inadvertently insightful
| louissan wrote:
| error 500 xD
| mberning wrote:
| Spending a few weeks on exploratory or speculative work is not
| really a huge time commitment. If it was going to drag on for
| months I would question it.
|
| I also challenge the "deliver in small PRs" idea. Yes in practice
| that would be ideal. But often when you are doing something
| completely off the map there is no point to submitting the PRs
| for the 5 things that didn't work. The author is falling into the
| same trap that scrum advocates and agilists fall into. Anything
| can be broken down into teeny tiny bit size deliverables and
| managed that way. Again, it would be ideal if that were the case,
| but sometimes you just need to give your best engineers some time
| and space to swing for the fences.
| heisenbit wrote:
| While this may be true there is real long term benefit gained by
| me trying hard for just a little longer: It takes time to truly
| understand the context and form an own point of view. I take time
| to find quality reference documents. I take time to do a few
| experiments. I take time to write down and order my thoughts.
| Asking someone if required when I have done my homework then
| yields faster and more effective responses. I get higher level
| responses that complement and extend my groundwork. Even if I
| believe I know the answer I find asking can help if only to
| establish and deepen relationships. Ultimately it moves me in a
| position where others come to me.
|
| Of course doing a submarine dive for weeks is never good except
| to serve as a straw-man for a blog post .
| TameAntelope wrote:
| I'm honestly surprised Jeff Atwood's excellent blog post about
| this hasn't been linked. [0]
|
| From his article: "It's effectively impossible to go dark if
| you're practicing any form of agile software development."
|
| There are a _lot_ of psychological reasons to "go dark", but
| very few (if any) solid business reasons.
|
| [0] https://blog.codinghorror.com/dont-go-dark/
| [deleted]
| blindmute wrote:
| I'm of the opinion that if the problems outlined in the article
| happen, it was because of poorly defined work. A senior engineer
| should be able to work on something with no communication for a
| week and it be correct. If it isn't correct, the work was not
| defined correctly prior to starting the work. Daily updates and
| frequent collaboration are not the solution; they are a stopgap
| masking unclear requirements.
| TillE wrote:
| That's basically true, but I don't think anyone has a good
| general solution to unclear requirements besides constant
| communication and fine-tuning, a la XP/Agile.
|
| I like working on a module with interfaces and behaviors which
| are set in stone, but I find most of my work is a lot more
| exploratory than that, so the "clear requirements" can only
| come after it's about 90% done.
| pcmaffey wrote:
| The challenging part of this is that knowledge work is intangible
| and uncertain. Showing progress is difficult, especially with low
| context. So we want things to be perfect or finished or at least
| to scope. There's a lot more that goes into our work than
| commits, PRs, and completed tasks.
|
| Second, "showing your work/progress" should be async. Otherwise,
| it's taxing for both parties as it requires a request and then
| some sort of feedback.
|
| People though are generally curious and want to know what others
| are working on, if they can help, how it aligns, etc. Having that
| ongoing visibility into each other's progress makes it way easier
| to build off each other.
|
| What we need is a simple, async way to share progress--outside
| the scope of tasks or timelines.
| babycake wrote:
| To be honest, I don't think this is any of the engineer's fault.
| I think we're an open creature by nature; we like to share and
| explore ideas with others.
|
| In the corporate field, what I've observed is that deliveries are
| most important. Not just any deliveries, but the project has to
| be big and "impactful" (as in, other teams use it too), and you
| personally have to own it. Like your name has to be attached to
| it. No one is going to remember your tiny fixes here and there,
| or tiny feature implementations in the larger system, even if
| it's tracked in sprint. All that stuff gets looked down upon as
| just 'doing your job'.
|
| To get any kind of recognition and ultimately, a promotion (or
| better raise, better rating, better bonus, etc), we absolutely
| have to clam up and take entire ownership of the work. If that's
| not done, other people can swoop in and steal the work. Things
| become need-to-know basis for your other fellow devs, design
| meetings is just you leading them and asking if this is fine,
| etc. Everyone has to know you're leading the project, and you
| have to constantly enforce that knowledge to put down any attempt
| at a takeover.
|
| I've personally witnessed this happening to an older and more
| senior dev when a college graduate tried to assert himself on the
| team until the senior dev fought back with office politics.
|
| In the end, office politics is what matters, along with your work
| to back up your office political agenda. Another senior dev could
| come in and take your project, claim your code is terrible and
| needs a rewrite, etc. You can only win if the boss is on your
| side, and that requires you to take on more than you can chew
| (and of course, deliver it all) to get on the boss's good side.
|
| Imagine if we didn't have that kind of pressure of delivery in
| the workplace just to get recognition. The first example that
| comes to mind is Open source work. People just contribute, we
| share and deliver openly, and as a result community projects grew
| so big our entire corporate infrastructure became dependent on
| it.
| quickthrower2 wrote:
| > Imagine if we didn't have that kind of pressure of delivery
| in the workplace just to get recognition.
|
| While the places I have worked might have a tiny element of
| this your situation sounds extreme.
|
| What I have seen is yes you do have to do "perception"
| management to keep a pulse on "how am i rated".
|
| Having a few long time trusted people vouch "this person is
| good" helps and all you need to do is work with them and show
| that you are good, both in attitude and capability.
|
| However your description sounds like a dystopian "house of
| cards" scenario that I would be looking for another job asap.
| If the programmers are more like politicians that is very odd
| and a bad sign.
| babycake wrote:
| I should clarify this behavior is mostly at larger
| companies... and although it's my anecdotal piece, it is what
| I've consistently seen at different companies and what my
| friends tell me they've experienced at other large companies.
| I've also worked at smaller places and this behavior was not
| as prevalent since everyone knows everyone on the dev team.
|
| Also, at larger companies your manager tends to reorg. I've
| gone through 5 managers in a single year before. And with
| them goes all the goodwill you built up during that time. New
| manager comes in, and it basically resets your 'perception'
| factor. The old manager might tell the new manager that some
| people are good, but you have to get lucky to get the new
| manager to care, because they haven't seen the results with
| their own eyes yet. That small time window is when it's ripe
| for someone to swoop in and claim ownerships of projects,
| while smooching up to the new manager. That's what happened
| with the senior dev I saw, but he had aces up his sleeves.
| What an epic showdown.
|
| Yea, I should leave probably, but it's just one burning ship
| to another. That's our fundamental reality.
| stephenboyd wrote:
| I can't imagine anyone on my dev team or the others at my company
| being able to spend multiple weeks consecutively on vaguely
| defined unplanned work. We collaboratively make a plan with
| product management covering many weeks of work (PI planning) with
| some date commitments on milestones we expect to achieve. Anyone
| spending a more than a few days on unplanned work risks making us
| need to revise the plan that we all made together, so we don't
| want to do that because the opportunity cost is obvious.
| quickthrower2 wrote:
| One way to address is for the manager to make sure the work is
| chunked down.
|
| Where I see the mentioned problem the most is when teams are too
| busy. The manager (as in team leader) is putting out fires and
| does not have the time and/or will to mentor and direct the team
| members that go off track.
|
| I think it is everyones job to make sure they are not too busy.
| Being too busy for basic processes is an antipattern and flag
| that things need to be reprioritised. Someone needs to walk away
| from the screen (or in covid times towards it) and talk to their
| boss!
| kinakin wrote:
| We see this with engineers of all ages, but especially with new
| grads. All have just spent 16 to 22 years working under a model
| where: you get an assignment, you come up with a solution, you
| are marked on your result, and then you move on...
|
| Our education has trained us that involving others is something
| done at the end.
|
| A lot of our new hires need help shifting their approach (and
| getting over insecurities) to consider that all their products
| need iterative review well before the work is complete.
| mkaic wrote:
| I'm not a new dev (but I am a new data scientist) and can
| definitely relate to what you said. I'm so used to "if you get
| stuck, just figure it out" as the norm for things I'm assigned
| to do, and getting used to "I'm stuck, I should reach out to
| someone who's more experienced than me" has been difficult. I'm
| always afraid of inconveniencing or interrupting my higher-ups,
| even though they never seem to be bothered by it. I guess it's
| just an irrational social fear.
| strict9 wrote:
| Insightful article but surprised at the recommendations. Teamwork
| is important, yes... but smaller task sizes should have been
| mentioned too.
|
| > _Finally, after several weeks, the engineer shares an update,
| and one (or many) of the following bad things transpire:_
|
| Several weeks? If you are giving developers open-ended tasks that
| take weeks or more to complete, imo it's asking for things to go
| off the rails.
|
| The most effective way I've found to avoid this situation is to
| ensure that worked assigned is broken down into tasks that are as
| small as possible.
|
| When assigned work is limited to small deliverables you get
| smaller PRs, limited business logic changes to get lost in, fewer
| integration changes, etc.
| jbay808 wrote:
| I'm currently realizing that laying out a moderately complex
| PCB can take more than a week, but there's not much to be
| gained from breaking it up into smaller pieces. You kind of
| just have to _do_ it.
| bob1029 wrote:
| Some problems are impossible to subdivide in a practical way.
| Having a team that can respond dynamically is really the only
| general solution I've ever seen.
| duxup wrote:
| Sometimes it is really hard to know that you've been out in the
| weeds for a while until you're there.
| bob1029 wrote:
| I am stuck with a delicate balancing act around this one.
|
| Our organization arguably would not exist today if it were not
| for developers doing "too much" work on things before bothering
| others. Our product would certainly be worthless trash today if
| we had to design by committee for every feature. We took
| extraordinary risks that simply could not have been planned into
| reality. Most of those risks were taken by individual
| contributors without anyone being explicitly aware of the
| magnitude of those risks.
|
| There is a price to be paid for asking permission. Especially if
| your team members lack the same vision/ambition and are unable to
| conceptualize the path you laid out. Clearly, this is a problem
| for both parties, but it is a big reason to sometimes go off on
| your own, build a whole goddamn thing in peace, and _then_ show
| it to the team. When others see a _complete_ solution, even if
| its not 100% what the business wanted, it makes the conversation
| substantially more productive. It 's the fear of the
| unknown/unseen that makes project managers nervous in my
| experience. Why start a hard thing at all if the conclusion is
| ambiguous at best?
|
| On the other hand, we lost ~4 major customers to technical
| iterations over time. This was something we could have avoided by
| polishing what we had at the time. Problem is, that thing we
| would have polished was an abject failure in terms of strategic
| sustainability for the organization and our customers at scale.
| TameAntelope wrote:
| I think it's telling when you call this "asking permission".
| You should never need to "ask permission" to give customers
| some small amount of value with a short turnaround.
| pphysch wrote:
| There's also the flip side to this, "doing too little work before
| looping in others". Management brings overhead. Meetings bring
| overhead. Not every (sub)project needs multiple ICs.
|
| That said, I think the E2E MVP/"tracer bullet" approach is a good
| compromise. It sets a clear milestone, which could be achieved by
| a single IC, but which provides something tangible for a team
| effort to build on (or meets intractable obstacles and and dies
| prematurely, saving everyone time before the PM engine is spun
| up).
| billforsternz wrote:
| I chronically suffer from this problem. For example I started
| working on my chess software in 2008 and just yesterday someone
| raised an issue on GitHub asking me about pertft(). Gulp.
| Fortunately it turned out my chess logic does pass that very
| specific, very easy to check correct/not correct test. But it
| would have been much better to have checked I was building on
| solid ground 13 years ago!
| aix1 wrote:
| Sorry, what's pertft()?
|
| (Could be a straightforward typo, but I'm not seeing it. Also
| clearly not important to understanding your point, but I'm just
| very curious.)
| billforsternz wrote:
| Whoops perft() sorry.
| escapedmoose wrote:
| But I don't _wanna_ talk to the other kids. :I
| emptysongglass wrote:
| The longer I work in this industry the more I reflect on the
| value of all this accretion of process: Agile, Scrum, PI
| planning, daily stand-ups are counterproductive to real work. So
| much of it, the sprints, the retroactives, the sprint planning,
| feel like taking place in the stead of real work. (I reached for
| the common "instead" of here but wanted to emphasize the work
| being removed or substituted by not-work).
|
| Real, deep work, is largely a solo affair. Teamwork is trusting
| your team that they will do their work.
|
| I can think of only two processes which truly requires
| communicating over real, smell-that-earth honest work. That is:
| seeking counsel and asking for help because you are well and
| truly blocked. For the latter, the process of learning enough to
| become unblocked, even if it takes a long time, can make the
| practitioner a better software developer forever vs the shortcut
| of a quick, "do you have a minute" disruption to another
| developer's time.
|
| Gumroad's philosophy and practice of work [1] struck a chord with
| me. No meetings, no deadlines. Just a commitment to production,
| whatever the method, whatever the schedule.
|
| [1] https://sahillavingia.com/work
| aetherspawn wrote:
| I think this can be done on purpose though.
|
| In some orgs, if you don't step around the problem carefully so
| as to not be "done" immediately with a proof of concept, it might
| get shipped to the customer from underneath you.
| thrower123 wrote:
| I've never known any serious work to actually get done without
| people "going dark" to actually accomplish it.
|
| The constant statusing that doesn't allow one four hours of
| uninterrupted concentration is demoralizing and grinds progress
| to a halt. There's a reason more code is authored between 9pm and
| 5am than between 9am and 5pm, but that wears engineers out badly.
| xbar wrote:
| This is really good, but I feel like you should have come to us
| with this topic sooner.
| JamesBarney wrote:
| > Encourage engineers to get something end to end launched
| internally as quickly as possible.
|
| Pragmatic programmer called this a "tracer bullet".
|
| https://builtin.com/software-engineering-perspectives/what-a...
| sdoering wrote:
| I was more often than not 'guilty' of what the author describes.
| And I actually love being the lone detective on the hunt for a
| cool solution.
|
| I am not a dev by trade (data analyst) but still love to work on
| problems solved in code.
|
| A lot of the advice hit home, but what struck me was this part:
|
| > Encourage engineers to get something end to end launched
| internally as quickly as possible.
|
| This is something my boss never ceases to tell us. When we build
| something we shall strive to have some first small thing end 2
| end done as soon as possible. Rough around the edges, not
| refactored, code being repeated - all fine. But it has to work
| end to end.
|
| Because we can brush it up and make it stable later. Because when
| starting we only have a vague feeling for the problem space and
| we need to learn the lay of the land by navigating it.
|
| I will always cherish this advice.
| kitsunesoba wrote:
| The frustrating thing is when only the first half of this
| philosophy (ship now, fix/polish later) is adhered to, where
| things get shipped frequently but seldom followed up on. The
| incentive to finish things needs to be strong for not only the
| engineers but also for the product teams and managers directing
| them, but as far as I can observe this is exceptionally rare --
| in fact it almost seems like the norm for non-engineers to push
| for shipping new features over polishing older ones. A lot of
| the engineers I know would love nothing more than the
| opportunity to polish the project they're responsible for to
| perfection, but are never given the chance.
| aimor wrote:
| I agree, but I've also tried to polish things without a
| strong need and it's difficult. The work can feel burdensome,
| useless, undirected, and sometimes requires major changes
| that can't be done (without inflating the scope of the work).
| sdoering wrote:
| I agree. I know that the freedom to create sensible
| architecture is a privilege.
|
| Even if other things may not be perfect (but what job is
| perfect in all areas), my boss knows the value of refactoring
| towards a stable and maintainable architecture while keeping
| a reasonable schedule for shipping.
| danielmarkbruce wrote:
| If you can present a metric which shows that said thing is
| bad on some dimension, and explain why it's bad for the
| customer (/business) and why what you will fix will improve
| it, and how much work is involved, you'll have a better
| chance of moving it through.
| beerandt wrote:
| It might be good advice, but that's not engineering in concept,
| spirit, or practice of the term.
|
| I don't usually pick an absolute, decisive side in the "what
| counts as engineering" debate, but this is the opposite of
| engineering.
| crehn wrote:
| This should nearly always include writing integration tests
| (that run on every change) to ensure you can refactor with
| confidence.
|
| If there are no tests, the team will waste a ton of time
| anxiously monitoring and reasoning about the messy code and the
| impact of their changes.
| sdoering wrote:
| I do. I even implemented tests for tracking code to be
| developed locally (including mocks).
|
| This way I'm able to quickly and confidently refactor as well
| as add to existing tracking code (web analytics).
| swagasaurus-rex wrote:
| I find when this happens, it never gets refactored. The edges
| can be smoothed, but the architecture is dried and hardens into
| something that needs to be worked around by everybody else
| touching the code. The easiest way to solve the issue becomes
| the only way.
| zoomablemind wrote:
| Depends on a team, of course. But happens often with business
| solutions. Done, whichever way. Next. It broke down in prod?
| Well, go fix it, it's yours now...
| sdoering wrote:
| My experience differs. But maybe because I love to refactor
| and create a clean architecture.
|
| Also I learned a lot from my boss' refactorings. Before that
| I never would have imagined how far a good abstraction can be
| driven.
| aimor wrote:
| I still find it amazing how many "first small thing end to end"
| wind up being the last major version for years. That's not a
| bad thing, I've grown to love it, and I think it's a tenet I
| should make a more conscious effort towards.
| Ensorceled wrote:
| I have two big rules for developers that report to me:
|
| 1. The 5 minute rule. If you are stuck for more than 5 minutes
| reach out. Once the developer is on the team for a while, this
| becomes 15 or 30 minutes.
|
| Caveat ... truly stuck ... tried a couple of things, googled,
| tried some more ... wondering what to try next.
|
| One thing I try to do with a new start is go ask them for help in
| the same way, "Hey, 5 minute rule, I'm think I'm missing
| something simple here."
|
| 2. Project Initiation Memo
|
| The is NOT a PRD, it is a high level "I think this is what I'm
| supposed to be doing on this project and why". It might turn into
| a PRD if one is warranted. It's really just a "did you understand
| the problem correctly"
|
| I've avoided so many massive f'ups or developers drifting into
| silent frustration for hours with these two rules.
| ketzo wrote:
| What's a PRD?
|
| Love the five-minute rule, by the way. I tried to apply that a
| lot especially when I was just starting at my job. So many
| things that I would spend two hours trying to fix, only to be
| told the next day that we had a super simple internal process
| to fix that thing.
| Ensorceled wrote:
| Product Requirements Document ... a full specification of
| everything the software needs to do.
|
| Sometimes VERY detailed, sometimes not so much.
| TameAntelope wrote:
| They could probably just write this in code, and save a lot
| of time.
| PaulHoule wrote:
| I've gotten in trouble too, particularly in open source projects,
| showing off a half-baked prototype that doesn't really prove the
| concept. If you need to win people over and it's a tough fight
| you need to be in a strong position.
| markus_zhang wrote:
| Actually, if we turn the perspective and look through the
| developer's eyes, the behavior makes a lot of sense.
| irrational wrote:
| > Throughout this initial period there are standup updates of the
| form "I'm exploring X, or working through problem Y, but should
| have something for others to take a look at soon"
|
| What is really going on is the developer has basically been given
| permission to not turn anything in. They are spending maybe an
| hour a day actually exploring/working on the issue and the rest
| of the day they are working on their own pet projects, playing
| games, watching netflix, whaterver. Heck, they might even spend
| just one day doing all their "exploring" and then see how long
| after that they can just show up for standup and extend out the
| "exploring" phase while doing whatever they want the rest of the
| day.
| leeoniya wrote:
| it really depends on what you're working through.
|
| i do this on occasion while experimenting and thinking through
| an architectural design. what matters is whether the end result
| is representative of the time spent on iteration and writing
| thrown-away prototypes. i will often not start writing code
| until a reasonable path is formed in my head, and then i may
| write a prototype that doesnt work out and have to loop back
| and rethink various aspects. it may take a week with nothing
| but vague updates in daily standups, but then something awesome
| to show that has gone through a bunch of private "pre-alphas".
|
| > For more senior engineers, it can happen because they like to
| work on their own and may be overconfident in finding
| solutions.
|
| this really only applies if you:
|
| A) dont have a history of delivering quality solutions to non-
| trivial problems
|
| B) refuse to ask for help/feedback when you actually need it
|
| typically, the rest of the team is working on other things.
| there would be little value in me pushing various crappy
| prototypes just for the sake of providing updates that only
| serve to distract people with information that will be out of
| date in 24hrs. "too many cooks in the kitchen" is a real thing,
| too.
| salt-thrower wrote:
| I think that's an overly harsh take. I've fallen prey to the
| pattern the author describes many times, and I inevitably end
| up making updates like that because I feel bad that work isn't
| getting done, which fuels a procrastination doom loop of
| anxiety and avoidance until I rip the bandaid off and hustle to
| make up the missing work.
|
| It sounds like you've never experienced this, and that's great
| for you, but don't discount what the author is saying. It rings
| uncannily true to me, and it sucks when it happens.
| nuancebydefault wrote:
| Exactly. It is very easy to fall into the trap the author
| describes, for junior as well as senior engineers. Managers
| should ask for feedback early on in the process. This could
| be a first draft of the architecture or even a simple bullet
| list of assumptions and considerations. A look at that info
| by a fellow engineer or a product owner can highly impact the
| set of requirements, the design or the way of implementing.
| alexfromapex wrote:
| I've been guilty of this at times but what I would add is a
| certain type of environment encourages this behavior. If the
| business or teammates are very reluctant to let engineers work on
| what they want or give harsh feedback it encourages people to
| retreat into their safe space and try to create something they
| feel is worthy of feedback.
| Phelinofist wrote:
| Can confirm. My lead is pretty picky with everything and
| expects 110% correctness. Even if my solutions works, is
| maintainable and extensible it is not how they would've
| implemented it, so it's no good. Argumentation is sometimes
| pretty artificial where some made up rules are the gold
| standard. That plus comments like "that is bad style" (for
| something that I've seen in all my past jobs + in a lot of OS
| code) make me not really want to loop them in.
|
| But the job pays well and has interesting problems to solve, so
| I guess I will put up with it for some time more.
| Steltek wrote:
| I think there's a new phenomenon that needs to be addressed:
| poor WFH communication channels. By encouraging radio silence,
| so as to not "interrupt anyone", things get missed.
|
| Also some people feel the need to tightly control group chat.
| Either content (no "offtopic"), membership, or # of rooms. Some
| chat platforms encourage this by restricting who can
| create/manage rooms or how rooms are linked together
| (discoverability).
|
| It's an unexplored area of knowledge for most people in the new
| WFH life everyone's leading.
| Buttons840 wrote:
| Yes. I do this because interactions with others are a net
| negative at my place of work. In terms of quantifiable rewards,
| 99% of interactions are +5 or +10, etc, mixed in with the
| occasional -15000. In the end the expected value of
| interactions is negative. All because of one or two very bad
| interactions a year; the rest being positive, but close to
| neutral.
| Cederfjard wrote:
| What kind of interactions are those extremely negative ones,
| if you don't mind elaborating?
| Buttons840 wrote:
| Most recent was learning we weren't implementing something
| in the way that was expected, which required a lot of
| rework and sparked conversations among management that our
| team was incompetent. We were completely blindsided by it
| all, leading to a feeling that any interaction might
| randomly turn into a similar debacle.
|
| But, when things go well they say "good job", so that's
| nice.
| disposableuname wrote:
| The original post contains
|
| > It can also happen if the team culture is toxic and engineers
| fear getting criticism early in the design process.
|
| I think the author would agree with you.
| zachlloyd wrote:
| i do agree
| vanusa wrote:
| Y-e-p. It's not like these retreats happen in a vacuum.
| folkhack wrote:
| I'll be honest - half the time it's trying to keep it from
| other engineers who are overly eager to have an opinion
| because a) they're low-output and looking to posture, and/or
| b) or want things to be done a different way.
|
| At least the business side of the house appreciates the
| spec'd work being accomplished.
| yjftsjthsd-h wrote:
| Intentionally not communicating things in order to prevent
| bikeshedding is a dangerous game to play and a symptom of a
| broken environment, but that doesn't mean it's not
| sometimes a valid approach.
| folkhack wrote:
| Agree - and it 100% comes from broken
| teams/environments/people. In engineering, I find most
| teams are more invested in tearing each other down more-
| so than building each other up - that's admittedly very
| anecdotal and personal to me.
| bryanrasmussen wrote:
| Or if teams are uncommunicative you can end up with not getting
| a usable response on concerns raised, need to march at some
| point and without feedback you decide to march in the direction
| that seems most reasonable to you. Later on it turns out that
| was right into the swamp.
| retinaros wrote:
| yeah. i agree it is a mistake. but I got many times sidelined or
| robbed of an idea or a project after starting it and involving
| other people too early. it happened for instance that I started
| developing a GDPR tool mentioned it to my manager, he then told
| me a few days later that there was a manager working on this and
| it was in the making. the manager in question never had anything
| on the topic, did not start anything as well. two weeks later he
| had a power point and hired an intern << to work on this topic >>
| he presented the deck to VPs, every one clapped said it was
| amazing. I had the full mvp working - demo-able and he was
| supposed to be the one leading this after this presentation.
|
| so I guess id rather do too much work before looping in others
| AtlasBarfed wrote:
| When you are doing idea creation and getting your head around an
| idea, I don't know about other people, but in addition to not
| being well quantifiable and structured (which standups and their
| tickets need), but looping in other people in the IT industry
| exposes you when you most look like an idiot.
|
| It's the same reason IT interviews are this big cockpuff show.
| Everyone is insecure due to a combination of impostor syndrome,
| constant tech churn undermining your expertise, stack ranking
| culture, our industry archetype of socially unskilled/introverts,
| projection of bullying from schooling, etc.
|
| So it comes down to functioning social dynamics in your group:
| people not trying to elbow other people in stack ranking, helping
| out, being eval'd fairly, etc.
|
| Things, you know, that IT companies and manager generally aren't
| good at because technical understanding and achievement is
| paramount.
| zachlloyd wrote:
| I'm the author of the post - would love any feedback / similar
| experiences / contrasting opinions!
| friendlydog wrote:
| I'm a fan of "always loop people in".
|
| Frequent checkins with detailed commit messages including
| markdown and graphviz diagrams which state intentions.
|
| Switching the flow from a status meeting low detail reponse of
| "still working on X issue" to a regular feed of detailed
| information which serves not only as a development log,
| documentation, but it crystallizes the developer's planning and
| thought process because they have to describe what they are
| doing rather than just "fixing the issue" , or "building the
| thing".
|
| Persistent chat has made daily stand up status calls redundant.
| Stakeholders can subscribe to channels which have rich detailed
| information about what is happening at any given moment. For
| larger groups a resource can curate the channels and provide a
| thoughtful summary in a higher level channel of different teams
| progress. Tools like Azure Dev Ops provide meaningful charts,
| tracking, and velocity, and the deeper conversations on chat
| linked to work items, wikis, and repo level filea serve to
| provide an accurate picture for anyone looking into the effort.
| Leads, and managers can identify trouble spots and adjust
| priorities or provide valuable insights. Regular demos can also
| be linked and serve as a historical record of the development
| direction.
| grumple wrote:
| I'm getting a 500 error when I visit the site.
| theandrewbailey wrote:
| I'm not sure what IC means. Integration Consultant? Industrial
| Control?
| conro1108 wrote:
| Individual contributor (as opposed to management)
| zachlloyd wrote:
| Correct! IC == individual contributor. Sorry for any
| confusion
| juice_bus wrote:
| I believe IC is "Individual Contributor" in this context.
| ilrwbwrkhv wrote:
| A most bizarre terminology the industry has come up with.
| Almost feels a bit derogatory.
| zaat wrote:
| That's the natural way languages develop, offensive terms
| replaces with euphemisms, given some time every
| euphemistic term become loaded with the same negative
| connotations of its origin and new euphemism get
| introduced.
|
| see:
| https://thelingspace.tumblr.com/post/114432905996/the-
| euphem...
| mLuby wrote:
| Individual contributor, in other words a worker as opposed to
| management. The author's using engineer to mean software
| developer; they're the workers in this context.
| alboy wrote:
| Itty-bitty Cog.
| disposableuname wrote:
| > as both an IC and a manager
|
| When juxtaposed to manager, it usually means individual
| contributor - someone being managed rather than doing the
| management.
| waynecochran wrote:
| I am an older software engineer and have noted that a lot of
| introverted engineers love to work in their own silos. Some of
| the smartest engineers are introverted and do not want to be
| bothered; worse yet, because of pride they often do not "suffer
| fools" well and avoid working with others. Working with a group
| of smart and _humble_ engineers that are constantly "borrowing
| each other's" brain is very effective and enjoyable experience.
| And everyone has a good sense of what everyone else is working
| on -- sunk cost is more frequently avoided.
| nuancebydefault wrote:
| I feel the same way. Lot's of experienced engineers don't
| like to be bothered too much, have the feeling they know best
| and just design and implement the way they have it in mind.
| Juniors on the other hand don't like to bring their beginners
| mistakes too much in the open, hence they work hard and long
| to avoid that. Both of these situation are largely sub-
| optimal. A good manager knows this and asks for feedback in
| time, in an interested way, without being too pushy.
| jkaptur wrote:
| It's great to see "I'm still exploring X" called out as a
| standup antipattern. I've heard and (hi Zach!) said this many
| times.
|
| ... But I've generally heard it most frequently from the tech
| lead and/or manager at the standup. It's easy to justify: "as
| the TL/M, my work is ill-defined, meeting-heavy, complex,
| externally-focused, and long-term! I'm not just building a
| feature! It's hard to describe!"
|
| In my experience, this culture percolates with lightning speed:
| more junior folks immediately understand that to be senior and
| high-status is to give vague updates (often with a dramatic
| sigh and a self-deprecating joke about getting nothing done).
|
| So it's good to exhort feature-building ICs to show incremental
| progress on that feature, but I think this article should have
| a heavier focus on the most senior folks at the standup.
| eatbitseveryday wrote:
| Please write the insight into the title of the post, rather
| than hiding it under a click-bait. Your site is down now due to
| traffic and the original HN title (reflecting the title of your
| writing) provides no value.
| zachlloyd wrote:
| yup, i messed this up, apologies. site is handling the
| traffic better now thanks to cloudflare
| jseban wrote:
| The description of the "problem" is that the requirements
| specified in the beginning were wrong, and then the developer
| is blamed for solving exactly what was specified, and not
| constantly asking management every day "have you changed your
| mind?". I don't understand at all, how this is the fault of the
| developer, talk about expecting the developer to bend over
| backwards for any product manager. How is it not reasonable for
| management/PO to be responsible for 1. sending devs off in the
| wrong direction, and 2. not notifying them as requirements
| change?
|
| This is just another way of saying "management is right, even
| when they're wrong, and you need to accept that".
| Jabbles wrote:
| Non-trivial problems often require exploration of the
| solution space. You're not expected to ask management if
| they've changed their mind, you're meant to present your
| finding so far, and ask if they have any feedback.
|
| Simply stating that you did as instructed is not a viable
| excuse for a human, that's not what they're paying you for.
| Computers can get away with it.
| jseban wrote:
| > Simply stating that you did as instructed is not a viable
| excuse for a human, that's not what they're paying you for.
|
| Getting paid for doing what someone tells you to do, is
| literally the definition of a job. What you're saying
| actually, is that it's not your job to do your job, it's
| your job to also do the managers/PO's job.
| 908B64B197 wrote:
| In this industry we use "developer" and "engineer"
| interchangeably, but one is not like the other. They don't hand
| out brass rats at the end of a bootcamp...
|
| > For early career engineers, it often happens because they
| lack practice working on teams. They train in school
| environments where they do classroom projects on their own, or
| work on long-term intern projects in a silo.
|
| Serious engineering school would have student work together to
| ship projects.
| afarrell wrote:
| Yes, MIT's university culture does genuinely encourage a
| collaborative project-based approach. However, some grads
| will believe that the business world expects them to be as
| brilliant as Tony Stark and able to "carry a message to
| garcia"[1]. If a course-VI grad wearing brass rat thinks a
| request for help/feedback will be rebuffed as impostor
| syndrome (it happens), they can make the same mistake. Ego is
| the enemy. The blog post's advice still applies.
|
| [1] https://courses.csail.mit.edu/6.803/pdf/hubbard1899.pdf
| which is both historically apocryphal and only good advice
| when dealing with an impatient and incurious leader.
| newsbinator wrote:
| > the biggest mistake I see engineers make is doing too much work
| on their own before looping in others.
| eatbitseveryday wrote:
| Thank you... frustrating we do not help by putting the
| statement into the title and write "bait-like" wording to get
| clicks and traffic. Now also the server is down so I get no
| value and no insight.
| dang wrote:
| It's sort of a reproductive strategy thing, only about
| attention. As I say about headline writers in media, it's
| their job to sex up the title and our job to knock it back
| down to size.
| zoomablemind wrote:
| The author obviously draws on own experience, thus the
| conclusions. However, an important aspect is the team and the
| process, not just the dev and their behavioral patterns.
|
| If a "loosely-spec'ed" feature is assigned to a single dev for
| implementation, then there must be either reasonable expectation
| that it could be delivered solo or that the blanks are not
| critical for the result.
|
| Either way, such "pattern" of a supposed dev-vs-team antagonism
| may be pointing rather at process deficiencies or disbalanced
| expectations from management.
|
| When team management believes that all is clear as day and could
| be done in a week-span, the devs may have a hard time affording
| themselves a prototype just to figure out what is there to do, so
| delaying the feature delivery is a simple hedge.
| taurusnoises wrote:
| Not a developer, like, at all. But, I see this in myself when I
| work in groups all the time. I get excited about the project,
| forge ahead on my own, come back with so much stuff, into which
| everyone else now needs to "fit". At which point the entirety of
| the collaborative intention is missed.
| gorjusborg wrote:
| https://archive.is/ZFwUh
| 24thofjan wrote:
| I'm curious about Zach's thoughts on how to use Github. Merge or
| rebase?
| 3pt14159 wrote:
| This is a bit of a nuanced topic with lots of shades of truth or
| context, and overall I agree with the article, but that said:
|
| Sometimes you know your team is going to do the stupid shortcut
| if you let them and you save them from themselves by solving the
| robust solution before they have a chance to "be pragmatic" and
| pointlessly bikeshed about things that don't matter to waste your
| time. Sometimes you know it will take you a week to do it right
| or a week with input to do it half right and you just bite the
| bullet and do it right the first time and, to the articles point,
| suffer the consequences if or when you get it wrong or partially
| wrong.
|
| Realpolitik is part of being a senior engineer. Sometimes you
| make the call to take the shortcut without mentioning it,
| sometimes you force the full solution with the big PR (or, even
| worse, a series of staged small PRs to make it look like you're
| taking feedback); but most of the time, if you're working
| somewhere good, you get to be completely transparent about what
| you're working on and the feedback you get is corrective and
| flexible.
| Slartie wrote:
| I have found that the attitude of "just silently do the robust
| and proper thing immediately and push it, instead of letting
| the entire team discuss this important infrastructure topic
| forever in order to ultimately come up with an abomination of
| design-by-committee-architecture, just to then find out that
| the remaining time now is way too short to implement it, which
| is why they then take all the stupid shortcuts to get it done
| in time, ending up with something barely holding together with
| duct tape that somehow works for the moment, but immediately
| tumbles down as soon as the next guy tries to build the next
| layer on top of it" is a very important senior dev skill,
| especially at the beginning of new projects when a lot of basic
| building blocks on which the more complex features have to rest
| later are still being created.
| TameAntelope wrote:
| The reality is that it's not your call, it's the customer's
| call, and you need to stop trying to make a decision _for_ the
| customer. Let them tell you what they want.
| davidhyde wrote:
| > "the biggest mistake I see engineers make is doing too much
| work on their own before looping in others"
|
| > "For more senior engineers, it can happen because they like to
| work on their own and may be overconfident in finding solutions.
| It can also happen if the team culture is toxic and engineers
| fear getting criticism early in the design process."
|
| Not saying the above statement is incorrect but here is an
| alternative explanation that is also viable: Senior Engineers are
| often hired into large large projects so that the company has the
| capability to address emergencies or modify the existing system
| accurately as it is often more difficult to work on a large
| complex code base than to build a new one from scratch. Those
| engineers sometimes never get to work on greenfield projects and
| "doing too much work on their own before looping in others" is a
| way to scratch this itch without the opportunity being taken away
| prematurely. It also offers chance to produce memorable work as
| nobody remembers the set of 3 point tasks you completed ten
| sprints ago.
| philote wrote:
| In my case, I'm the senior engineer and the rest of the team
| are juniors. There's generally not much I can ask them that
| they'd know the answer for. On the other hand, looping them in
| is a good learning experience for them even if they can't help
| me solve the issue. But due to time constraints that isn't
| always possible.
| EGreg wrote:
| You nailed it. Senior engineers build things on their own
| because their company can't afford to hire enough advanced
| enough people who can learn the system and take over the work
| without being trained for 6-12 months, and often there is no
| budget for this kind of "distraction" from the core
| moneymaking path.
| abofh wrote:
| You are not wrong. I generally sell as a mercenary, and prefer
| it that way - I've been doing this longer than some of my
| managers have been alive. I'm paid just as well if they want to
| "pair program" or jira the whole process, but yeah, you hired
| me to fix a problem - if you _are_ the problem, I get paid just
| the same.
|
| Welcome to the real world, if your work is interesting, the
| clock might not turn on when I'm having fun. If your work is
| bullshot, I bill tighter than my lawyer
| Victerius wrote:
| > I've been doing this longer than some of my managers have
| been alive.
|
| In what organisation do 25 year olds manage 50 year olds?
| Ensorceled wrote:
| My first job out of university, I was promoted to manager
| in my mid 20s. One of the senior engineers reporting to me
| had kids older than me.
|
| Now, they were PAID a lot more than me ...
|
| The first thing they taught me was that it wasn't my job to
| do the work, because it didn't matter how smart I was, I
| didn't have almost 30 years experience.
| SkyPuncher wrote:
| Not as extreme, but not far off. I believe I'm the youngest
| person on the team I manage.
|
| I've spent a lot of time in startups - including way too
| many hours in my 20's working on side-hustles (wife was in
| med school, so it was kind of my thing to do). I've ended
| up in a situation where my technical skills are strong (but
| not the best on my team), but my business/startup knowledge
| is much better so I can help to ensure everyone is working
| towards the most impactful/valuable outcomes.
| superfrank wrote:
| I worked at a start up where the founders were 25 & 26 and
| most of their first 25 employees were their friends who
| were similar aged. In less than two years, there were
| almost 100 employees, plenty of which were in the 50s.
|
| The company's last valuation has it worth over a billion
| dollars now and they have a few hundred employees. A good
| chunk of the C suite and VPs are still those same early
| employees who are now in their late 20s and early 30s. Some
| are managing former FAANG employees in their 50s.
| mbrameld wrote:
| It's not unusual in the US military for a lieutenant or
| captain in their early 20s to manage many senior non-
| commissioned officers in their late 40s.
| dfsegoat wrote:
| No mil. experience myself, but I'd say that while the
| officers may technically 'manage' the NCO's, that with
| few exceptions it is the NCO's that actually get things
| done.
| throwawayboise wrote:
| Yeah the officers all move on relatively quickly; the
| NCOs may be on the same ship or class of ship their
| entire career.
| perfect_wave wrote:
| I'm a 25 year old managing a global team of 8 people. I'm
| self-conscious about my age both in my 1:1s with my reports
| and when talking with customers. That being said, it seems
| like things are going well. My team is doing great metrics
| and achievements wise and the company we work for tripled
| in size in under a year.
| foobarian wrote:
| You know what I usually tell my managers. "Thank you for
| your service" :-)
| asow92 wrote:
| A few years ago, I was a "team lead" at the age of 27
| managing a team that included one developer over 50 at a
| big TV network company.
|
| We're both at different companies nowadays, but I've been
| trying to get him started at my current company's team
| (which I am senior on, but not a lead) for a while now and
| he's considering it!
| ipaddr wrote:
| Many organizations and it is a normal thing.
| ttymck wrote:
| Could a 30 year old manage a 60 year old? Certainly a 35
| year old could manage a 57 year old?
| bayindirh wrote:
| If the 60 year old is wise and humble and 30 year old is
| open minded and not smug, it'd create a hell of a
| learning environment.
| FpUser wrote:
| Definitely. Just do not micromanage and drag to endless
| useless meetings.
| scrumbledober wrote:
| I have met several engineers that were very much senior to
| their managers but did not want to make the shift from IC
| to management.
| Hermitian909 wrote:
| I've known people who submitted working patches to the
| Linux kernel at 13, which I'd say is a reasonable start for
| "doing this". A 30 year old managing a 43 year old would
| not be strange at all.
| dhosek wrote:
| Exactly, I started programming in AppleSoft BASIC when I
| was 11, picked up 6502 Assembly and Pascal before high
| school and added C, Rexx. 370 assembler and FORTRAN
| before I started college. I was 28 the first time I had a
| manager younger than me. I think the last time I had a
| manager older than me was when I had a job where my
| direct report was to the CTO.
| galdosdi wrote:
| Anecdote, but this was the approximate case on the team I
| worked on at Google (Manager in his mid 30s, team mostly in
| their 20s with one in his 50s). It happens. Actually, it
| was nice to see, as some evidence of non-ageism.
|
| I hope to no longer need to work by the time I'm 50, but
| nobody knows what the future will bring, so I'd certainly
| like to have the option just in case!
| smcleod wrote:
| In a previous job I was team lead of a team that had a
| person in they're 40s and one in their 50s, I started as
| lead as a 23 year old and moved on when I was 30. There are
| many things I'd do differently now, but it was an effective
| and impactful mostly high functioning team. It does happen.
| imoverclocked wrote:
| A lot. Technical managers need not be experienced technical
| talents who have made a potentially incompatible shift to
| management.
| icedchai wrote:
| 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.
| ipaddr wrote:
| An experienced manager is not easy to bullshit
| regardless. Sometimes a non-technical manager is better
| for many reasons. Having business domain experience can
| be just as valuable
| Ensorceled wrote:
| > Welcome to the real world, if your work is interesting, the
| clock might not turn on when I'm having fun.
|
| Ha! Yeah, I worked on a really cool project for a charity a
| few years ago: "How many hours is this going to cost us this
| week, you were working like a warrior?" "35"
| amelius wrote:
| > If your work is bullshot, I bill tighter than my lawyer
|
| Lawyers must hate their work.
| Taylor_OD wrote:
| I believe it has one of the lowest job satisfaction of any
| white collar jobs. I've wondered that is folks didnt have
| the massive student loans to pay off early on if they would
| stick with it.
| BurningFrog wrote:
| Many law firms are incredibly well paid sweatshops.
| skissane wrote:
| > 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, at a work function (previous employer), I met one of
| the lawyers from the contracts department. He was telling
| me how he used to live in a rural area doing agricultural
| real estate transactions, now he had moved to the big city
| to do in-house contracts review for a multinational
| software company. He was a top performer (indeed, this was
| a function to reward people who'd been nominated as "top
| performers" by their management)-but he didn't give me the
| impression he really loved what he did, more that he was
| just doing it to support his family.
| zachlloyd wrote:
| i see the point here.
|
| i do think giving space for hard work is important. i still
| more often see the opposite problem of too much silo'd work
| leads to wasted effort, but for some really hard problems,
| having a bunch of space to think them through is beneficial.
| ravenstine wrote:
| Yes, I think this is undoubtedly true. I didn't really learn
| until I advanced my career that, in some respects, being a
| junior or mid-level developer is actually _better_. Being a
| senior can be a slog, and while I got paid little in earlier
| positions, I actually got to do more interesting things, screw
| up more, and build things from scratch.
|
| The other thing that can encourage doing too much work before
| looping in others is the culture of the team. You are lucky if
| you can amass a team of people who all have the same attitude
| of talking to each other frequently and handling a certain
| level of interruption. I've worked on such teams and miss them.
| Although pretty much everyone at any company you work at will
| say "ask questions, don't hesitate, blah blah blah", there are
| teams where people go _weeks_ not talking or sharing work, and
| everyone is always too busy to get interrupted. If work gets
| assigned in large chunks, as can happen for seniors in
| particular, it can also just not make sense to loop in someone
| temporarily if more time needs to be taken for the other person
| to catch up.
| rory wrote:
| A good point, but the reason I have (and fight) this problem is
| much simpler:
|
| I like writing code. I dislike talking to people.
| 6gvONxR4sf7o wrote:
| > 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.
| skrtskrt wrote:
| To me moving beyond senior means you enable the entire team
| to contribute together accomplish Big Memorable Things.
|
| This can mean a ton of things, which cannot all be served by
| a single senior+ engineer:
|
| * mentorship
|
| * seeking out, establishing, and evangelizing best practices,
| and not just coding best practices: architecture,
| documentation, testing, ci/cd etc
|
| * high-level architecture knowledge and experience
|
| * evaluating technology choices: tooling, databases,
| orchestration platforms, etc etc
|
| * assisting management and product with scoping and
| prioritizing work
|
| * the ability to put your head down and crank out a solution
| to something in code simply because it needs done and you can
| do it better and/or faster than others
|
| * laying the framework of a greenfield project, maybe
| sketching out the codebase or POC for juniors to take and run
| with
|
| * ...and so on and so forth.
|
| A single person may be able to contribute all these things to
| a team over a time frame of multiple years, but in a 3 or 6
| month time frame, most mortal engineers could only contribute
| two or three.
| belval wrote:
| I mean it's not that toxic, if you are a good worker bee your
| manager will usually notice and be happy with your
| performance. Then from time-to-time you branch off to do
| something more high-risk to add to your promo doc.
|
| I think a lot of people have weaker communication skills than
| execution skills. So they could loop in everyone early on,
| but their idea might get killed off because they failed to
| justify it properly. If instead they leverage their execution
| skills and make an MVP that will speak for itself, then they
| bypass that issue.
| 6gvONxR4sf7o wrote:
| Maybe toxic is the wrong word. Perverse maybe. But I don't
| think that being a good worker bee often gets people past
| the senior level, at least from what I've seen. But also
| getting past senior is rarer, so maybe what I've seen isn't
| representative.
| FpUser wrote:
| >"if you are a good worker bee your manager will usually
| notice and be happy with your performance"
|
| And other than some bonus never promote you. If you have
| capability to be anything above that "worker bee" say / ask
| exactly what you want. If not look for another job. While
| this SCRUM / Agile bullshit is wide spread and even works
| in some specific circumstances there are enough companies
| that are not hung up on moving pins on dashboard and where
| one can really grow.
|
| Work for yourself. Work with the manager, not for manager.
| belval wrote:
| > Then from time-to-time you branch off to do something
| more high-risk to add to your promo doc.
|
| I agree, that's exactly what I wrote.
| sodapopcan wrote:
| Exeactly. There is too much emphasis put on rewarding those
| who make big, disruptive change and large, solo wins. Someone
| making a lot of little wins are just as valuable yet usually
| don't any great accolates for it. Not to mention, putting one
| person on a large-ish project is a great way to create silos.
| closeparen wrote:
| 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
| leave.
| pojzon wrote:
| I've faced worse issue. So you are thinking about problem
| solution, you created a design and you ask ppl for their
| opinionated view about the problem and your solution.
|
| Issue is - they cannot even give you a good feedback because they
| are not that advanced.
|
| The issue of being a great engineer is that there are not many
| great engineers you can have a constructive discussion with.
|
| You are sometimes even "expected" to deliver solution alone,
| because there is noone who even grasps the concept.
|
| One could say its simply an incorrect team composition in this
| case but well.. what can you do about it when you are also asked
| to in the same time train ppl who clearly dont have the capacity
| to match your level - and better - they are supposed to reach
| that level soonTM.
| reureu wrote:
| Amen to this. In a similar vein, in a heavily resourced
| constrained environment, the rest of the team may be really
| competent but be struggling to meet their own deadlines so just
| don't have the mental bandwidth or time to provide any
| feedback.
|
| I've had this issue at a few jobs in the past, and I know I've
| come off as the lone developer who ventured too far... but at
| every step along the way I stopped, sent in a PR, scheduled a
| meeting, etc but got virtually no engagement. And I was still
| getting pressure from stakeholders to deliver, so had to keep
| moving :-/
|
| I think OP brings up an interesting problem, but I don't think
| the solution is often as easy as sending in earlier PRs. It
| might actually be a structural or cultural problem in the
| organization.
| cercatrova wrote:
| The mistake is "doing too much work on their own before looping
| in others."
|
| Can we edit the title to remove these kinds of clickbaity titles?
| dang wrote:
| Sure.
| [deleted]
| Ozzie_osman wrote:
| We have a saying on our team, "don't go down the rabbit hole
| alone".
|
| Honestly I think the reasons mentioned in the article for why
| this happens are valid, but more frequently, people are a little
| insecure about their work or a little too much of a
| perfectionist, and that creates slightly enough friction to deter
| them from sharing progress or asking for help early on.
| commandlinefan wrote:
| This whole post strikes me as somebody making up a world as he
| believes it ought to be and then suggesting advice for navigating
| _that_ world, rather than the real one. For example:
|
| > Always encourage engineers to show their work as quickly as
| possible
|
| Yep, that sounds like _great_ advice. On "paper", anyway. I
| tried to do that when I first started out, too. What I found was
| that communicating "this is just an early draft, it'll be better
| when I'm finished" was well-near impossible, no matter how hard I
| tried.
| adverbly wrote:
| They missed one reason why it can happen: Because doing things
| "the right way" is too slow, and the engineer is trying to skirt
| around process because the company moves way too slowly. Not out
| of malice or negligence, but out of a fear of the megacorp
| killing agility. I've seen entire teams at megacorps or
| governments try to keep others in the dark with projects that
| would be crushed under strict corporate rules.
| gmfawcett wrote:
| It doesn't have to be a megacorp. Looping new people into a
| deep problem takes time, and can kill momentum if not done in a
| strategic way. Your personal time on any problem is finite, and
| you can exhaust that time-budget on bringing the wrong people
| up to speed. This is doubly true when the other person isn't on
| your team or in your organization: e.g., bringing in vendor
| support. (Maybe your experience is different; in mine, bringing
| in remote experts doesn't guarantee a faster resolution.)
| Veuxdo wrote:
| Sometimes you have to dive into a problem, experiment, try things
| out.
|
| There is such a thing as premature collaboration.
|
| If you want to be truly great at something, you need to practice
| it consistently by yourself.
| pojzon wrote:
| Indeed, question made by managers is:
|
| "Can you train in spare time?"
|
| "While working on your own projects"
| Trasmatta wrote:
| I'm good at working on a team and looping in others. I also find
| it to be one of the most exhausting parts of software
| development. It's so difficult to constantly need to get feedback
| and buy-in from other people, and takes away a lot of the
| creativity and joy in programming (for me).
|
| Which isn't to say you shouldn't do it, just that it's one of the
| things that makes me dislike working on a team. I actually think
| this may be one of the factors in burnout for a lot of
| developers. Writing code as a team is almost like writing a novel
| with a few dozen other people, all of which have differing ideas
| on how the book should be written, or even what it should be
| about. It's hard to feel the joy in creating something when
| you're only a small cog in the development machine, and every
| decision needs a dozen voices of input.
|
| It's disempowering to feel like you're never able to make a
| decision yourself, despite supposedly being hired for your
| expertise in the field.
|
| > Always encourage engineers to show their work as quickly as
| possible - an engineer on a project should never go more than a
| week without showing something, and usually it should be more
| like a day.
|
| "usually it should be more like a day" is bad advice in my
| opinion, and a likely source of micro management. Let
| professionals do their work.
| Panoramix wrote:
| 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.
| TameAntelope wrote:
| 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 16 hours of work.
|
| If you can't work at that cadence, you're probably not being
| as effective as you could be, as a developer. A "good"
| manager enables you to work like this.
| beefield wrote:
| Thanks for this comment. It pretty much confirms my hunch
| that I would not be happy in a "developer" role. I have
| done quite a lot work that requires writing code. But often
| it has been projects with literally months before there has
| been anything that anyone might call functionality.
| mh- wrote:
| Please don't over-index on this comment. It's pretty out
| of touch with how the majority of the field works.
| dogleash wrote:
| I used to work at an R&D company. While that cadence is
| possible in a website mill, it's a laughable blanket
| statement.
| gffrd wrote:
| Just wanted to say thank you for "website mill" ... I'm
| reminded of this stark difference when talking with a
| friend who builds ultrasonic hardware.
| [deleted]
| Trasmatta wrote:
| I strongly disagree with this. This is an approach to
| development that encourages an extremely limited and short
| term view on development that leads to low quality software
| and unhappy developers. It's also only remotely possible
| with a certain type of software.
| yibg wrote:
| For larger pieces of work, some times it takes me more than
| a day to just figure out what's where and where I can even
| get started. I guess I can still give updates daily, but
| it'll just be "still investigating".
|
| Hell, I've fixed 1 liner bugs that have taken me a week to
| figure out.
| mattferderer wrote:
| As much as I love the feeling of writing something clever or
| that feels really well done, I hate the feeling of realizing
| it's the wrong thing even more.
| Trasmatta wrote:
| Agreed, and that's why I mentioned I think you shouldn't just
| silo yourself. That doesn't seem to work either. I don't
| really have a good answer or alternative, more just pointing
| out how the dynamics of team based software development seem
| to be optimized towards burning out programmers. I don't know
| how to fix it, but it seems to be a problem.
|
| A first step is probably treating your developers skilled
| specialists (hopefully you've hired a good team, of course),
| and not just code monkeys who have to show their manager a
| progress report every single day.
| peakaboo wrote:
| You do know how to fix it - you don't loop in others until
| you want to.
|
| The problem is our industry, forcing developers to exhaust
| their energy on pair programming in open offices. May as
| well be in a daycare center with children all around.
| Trasmatta wrote:
| Ugh, my worst development job ever was one that had
| mandatory full time pair programming. Full time pairing
| is one of the worst ideas ever conceived in the software
| world.
| onemoresoop wrote:
| Pair programming should be optional and for whoever wants
| to get team members (especially juniors) up to speed and
| on the same page. It could be very productive but like
| all methods/tools that are shoved down everyone's throat
| and forced to apply them, I could see them being a
| disaster.
| Trasmatta wrote:
| I generally enjoy pair programming when utilized
| occasionally and as needed, but mandatory pairing is just
| horrible.
| onemoresoop wrote:
| Each tool has its use case. Forced use results in misuse.
| dhosek wrote:
| I actually found it quite helpful, not just for getting
| up to speed. After moving to another division of that
| company that didn't employ full-time pair programming, I
| saw code of noticeably lower quality being produced. That
| said, it was emotionally exhausting for me to do full-
| time pairing and I'm not sure I'd go back to it.
| [deleted]
| daenz wrote:
| The trick is to make the "right" decision yourself while
| helping people feel like they were heard and had a chance to
| give their input.
|
| From my experience, people don't actually want to control the
| output of everything, they just want the opportunity to be
| heard. What you do with it from there doesn't matter as much,
| so long as the desired outcome is "correct". If the desired
| outcome is not correct however... then you have to justify all
| of the input that you didn't act on.
| Trasmatta wrote:
| The tricky part for me is that sometimes I did actually need
| that input from others on the team. Sometimes it's all just
| bikeshedding and a waste of time, but sometimes it does help
| me from going down a rabbit hole that might have wasted weeks
| of development.
|
| But regardless, I find that whole process exhausting and
| disempowering, even if there is sometimes a benefit from it.
| peakaboo wrote:
| Completely agree with this, and this is why I simply don't loop
| in others.
|
| I wrote a program the way I think it should be. Clean code,
| super easy to understand, super low complexity. Anyone can
| understand what it does.
|
| Thats fun for me, when the code is very simple, reads like
| English and there are no complex functions.
|
| I don't do real software engineering however (just business
| intelligence and python programs to extract and load data). But
| when it comes to looping in colleagues, I avoid it for the same
| reasons as above.
|
| Its exhausting.
| drawkbox wrote:
| > Writing code as a team is almost like writing a novel with a
| few dozen other people, all of which have differing ideas on
| how the book should be written, or even what it should be
| about.
|
| I use this exact description when discussing balancing creative
| side of the value creation project processes, design and
| development over the value extraction side of products. Small
| empowered teams with an almost startup mindset is key, but even
| more is time to play to find solutions that can make products
| that are more like friends than enemies to people.
|
| Engineering/development, creative and product
| design/development are creative fields, a value creation action
| and activity.
|
| Business, finance, marketing do not see many parts of this as a
| creative action but a production line, a value extraction
| action and activity.
|
| A large problem is the misunderstanding that new projects are
| value creation not just value extraction, and rely on
| creativity at inception. Once they are established they can be
| more patterned and predictable and ramped up, but initially the
| creative phase is the key to making good products. Smaller
| teams, more empowering of the people that can create products
| that get the early points right. Taking long enough in the
| "open" mode before the "closed" mode is key, essentially
| prototyping and play is needed, but rarely available in the
| modern processes and project management systems where
| engineering is simply "production". There is a pre-production
| and post-production that is usually left out.
|
| For instance in game development, pushing through a project
| process before the main game mechanic is "fun" is a problem.
| You can't get creative on a forced schedule just as you
| couldn't write a book that way or come up with a novel new
| concept in some software app that should be a friend to users.
| The prototype of the project or product must have some time to
| simmer and iterate on. The first thing managers do is cut that
| time and sometimes throw too many people at it resulting in
| Mythical Man Month level mistakes leading to too many cooks.
| When a prototype or early product has value mostly figured out,
| then it can go into a more robust process to create variations
| or iterations. The initial value creation will always be wildly
| hard to estimate.
|
| Good examples of this in software are programming languages,
| usually it is one person for a long time then others join in to
| ramp up when the vibe of the language is set. Same with books,
| movies, games, anything really. You can't have 10 people
| drawing the same illustration or writing the same book, the
| parallel part can be multiple people doing their own to see
| which is best, but you can't have them all in on one creative
| project without it being confused.
|
| I have seen companies turn into faction based wars when varying
| groups don't clearly respect the value creation and value
| extraction balance, the value creation MUST come before the
| value extraction. The open mode before the closed mode.
|
| A great talk by John Cleese on the "open" and "closed" mode [1]
| helps describe this, which I recommend and hope everyone I work
| with watches. Value creators need time and creativity to create
| value both in the "open" mode to explore/prototype/build and
| the "closed" mode when things are decided to ship. The value
| extractors always want people in the controlled "closed" mode
| only, the "open" mode is non quantifiable and seen as almost an
| enemy to the value extractors but is key to creating products
| that are so good they are like friends to value creators and
| the people using the products.
|
| The value extractors are who Fred Brooks talked about in the
| Mythical Man month [2], they think things are a factory with
| already figured out steps, when you are in a field that uses
| originality, creativity, the mind over the physical, it isn't
| like a factory or supply line. Every single project manager
| needs to know about the Mythical Man month.
|
| Here's a great point by Steve Jobs about product stagnation and
| the managers/business side [3] and how they can run amok if not
| controlled to allow value creation to continue, and how
| monopolies or problems that arise when only the
| business/managers are in charge. This point is more about
| larger companies than new projects but the same forces that
| stop innovation at large companies also kill it in any sized
| companies when there is no value creation / value extraction
| balance.
|
| > _It turns out the same thing can happen in technology
| companies that get monopolies, like IBM or Xerox. If you were a
| product person at IBM or Xerox, so you make a better copier or
| computer. So what? When you have monopoly market share, the
| company 's not any more successful._
|
| > _So the people that can make the company more successful are
| sales and marketing people, and they end up running the
| companies. And the product people get driven out of the
| decision making forums, and the companies forget what it means
| to make great products. The product sensibility and the product
| genius that brought them to that monopolistic position gets
| rotted out by people running these companies that have no
| conception of a good product versus a bad product._
|
| > _They have no conception of the craftsmanship that 's
| required to take a good idea and turn it into a good product.
| And they really have no feeling in their hearts, usually, about
| wanting to really help the customers._
|
| Modern project management processes promote shallow change over
| deeper dives. They create a risk profile for anyone looking to
| bring new innovations that might be hard to estimate because it
| will be a perceptual hit. These rigid tightly wound processes
| are horrible for creativity. Agile itself has been captured
| with tightly wound controlling mechanisms like the daily
| standup, and so much weight around trying new things as well as
| perceptual hits for that. Anyone truly trying to make new value
| will be seen as an enemy to these systems. Agile was created to
| give product people more margin to build, but it has been
| coopted into being used to control creativity which cannot be
| controlled, it simply disappears when there is no open mode and
| only a closed mode or nothing but value extraction.
|
| All of this is spelled out in "How Software Companies Die" as
| well [4]. I wonder when if these realities will make it into
| the business education curriculum.
|
| [1] https://www.youtube.com/watch?v=Pb5oIIPO62g
|
| [2] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
|
| [3] https://www.businessinsider.com/steve-jobs-on-why-
| innovation...
|
| [4] https://news.ycombinator.com/item?id=1866486
| Trasmatta wrote:
| I don't have a lot to add except to say I loved this reply. I
| think a lot of people might miss it since it's down in the
| replies, maybe you could expand on it, and make it a blog
| post at some point?
| drawkbox wrote:
| Thanks, your post also resonated when you mentioned exactly
| the way I see it. I will be writing up more on this as it
| is a theme of mine and have quite a bit here at HN, and
| other areas where value creators are.
|
| Good news is there are lots of us like it, the problem is
| since the value creators rarely control the funding and
| sometimes lose the power to implement these the right way
| before internal faction wars start. However at all good
| product and all good companies, you'll see the respect of
| value creation and the open mode. One day maybe
| business/finance will see it with the same value.
|
| A couple of points as well, there is an internal and
| external view of a product. The external view is really all
| that matters, the market perception. The internal
| perceptions and processes if they are made too tight or the
| main focus, the external product suffers. This is one
| reason I think remote companies that are smaller, or having
| small teams, do better. They focus on their external view
| over the internal. Most remote work is virtual just like
| most communication today and especially the communication
| with the people that use products. The external view needs
| to be the main focus as well as simplicity, but also the
| "friend" aspect of a product. Using a product should be a
| simple joy, a friendly part of your day. External focused
| setups work the best to achieve that.
| n0w wrote:
| > _Writing code as a team is almost like writing a novel with a
| few dozen other people, all of which have differing ideas on
| how the book should be written, or even what it should be
| about. It 's hard to feel the joy in creating something when
| you're only a small cog in the development machine, and every
| decision needs a dozen voices of input._
|
| This resonates with me. I think we do our best work when we
| have the autonomy to apply our expertise.
|
| But at the end of the day, you're not the only one writing that
| novel. If you have an idea of where the plot is going but your
| teammates think it's heading somewhere else, it's going to be
| very problematic.
|
| The other problem is that you _will_ make mistakes. Some could
| be avoided by leveraging the experience of your teammates. You
| also won't always strictly have the best ideas. Brainstorming
| as a group can be a lot more effective than sitting alone for a
| long time thinking hard about a problem (but also sometimes
| hard problems need a lot of individual thought).
|
| I suppose my point is that I'm not sure where the happy medium
| is? I've been on both sides of the "engineer working too long
| alone before sharing" problem and I think it sucks.
|
| How do we enable engineers to do their best work but also allow
| our teams to be successful?
| rurp wrote:
| Due to some turnover I ended up working mostly independently
| for about a year at a previous job. Nobody cared one bit about
| the code I wrote, just the end result. Overall it was great! I
| was surprised at how productive I was in that time. I'm not a
| partiularly amazing developer, but I managed to ship a ton of
| work that held up quite well.
|
| Obviously there are limits to this approach and it wouldn't
| work well for solving really difficult problems, but really,
| 99% of day-to-day development work isn't that special. A
| motivated and conscientious developer with average skills can
| get an awful lot done with minimal distractions.
___________________________________________________________________
(page generated 2022-01-25 23:00 UTC)