28 ms·
Doing too much work on one's own before looping in others
- mjrbrennan 5y agoI absolutely hate hate hate having to do rework at the end of a feature or other project, so I loop others in with design discussions early and often. I don’t want to get to the end of something only for someone to say “Oh wait I think it should be done this way.” Communication is key.
- zachlloyd 5y agoI'm the author of the post - would love any feedback / similar experiences / contrasting opinions!
- theandrewbailey 5y agoI'm not sure what IC means. Integration Consultant? Industrial Control?
- mLuby 5y agoIndividual 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.
- conro1108 5y agoIndividual contributor (as opposed to management)
- zachlloyd 5y agoCorrect! IC == individual contributor. Sorry for any confusion
- juice_bus 5y agoI believe IC is "Individual Contributor" in this context.
- ilrwbwrkhv 5y agoA most bizarre terminology the industry has come up with. Almost feels a bit derogatory.
- zaat 5y agoThat'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-euphemism-treadmill https://thelingspace.tumblr.com/post/114432905996/the-euphem...
- Sohcahtoa82 5y agoBetter than grunt, peon, peasant, minion, or drone.
- disposableuname 5y ago> as both an IC and a manager When juxtaposed to manager, it usually means individual contributor - someone being managed rather than doing the management.
- alboy 5y agoItty-bitty Cog.
- grumple 5y agoI'm getting a 500 error when I visit the site.
- eatbitseveryday 5y agoPlease 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 5y agoyup, i messed this up, apologies. site is handling the traffic better now thanks to cloudflare
- 908B64B197 5y agoIn 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 5y agoYes, 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 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.
- waynecochran 5y agoI 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 5y agoI 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.
- jseban 5y agoThe 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 5y agoNon-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 5y ago> 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.
- Jensson 5y agoYou also get paid to be the scapegoat for when your manager fails to do his job, like in this story.
- friendlydog 5y agoI'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.
- jkaptur 5y agoIt'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.
- chrismorgan 5y agoI 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.
- alexfromapex 5y agoI'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.
- vanusa 5y agoY-e-p. It's not like these retreats happen in a vacuum.
- peterangular 5y agoI'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 5y agoIntentionally 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.
- peterangular 5y agoAgree - 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 5y agoOr 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.
- newsbinator 5y ago> the biggest mistake I see engineers make is doing too much work on their own before looping in others.
- eatbitseveryday 5y agoThank 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 5y agoIt'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.
- eatbitseveryday 5y agoI guess that makes sense. But it is more work for me. And for those who don’t want to or can’t put the time into it (outside of HN) they eat what they are fed.
- ziggus 5y agoWhy the conflation of 'engineer' and 'developer'? That's a bit confusing.
- spmurrayzzz 5y agoI'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 5y agoI 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 5y agothere'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 https://www.stilldrinking.org/programming-sucks
- spmurrayzzz 5y agoThis 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.
- gorjusborg 5y agohttps://archive.is/ZFwUh https://archive.is/ZFwUh
- zachlloyd 5y agoworking on the issue with the site going down. more traffic than i expected...
- mt_ 5y agoWould you consider that a mistake most engineers make?
- uejfiweun 5y agoI 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 5y agoI 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
- zachlloyd 5y agoRight, 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
- claylimo 5y agoWhere 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.
- alanbernstein 5y ago> Internal Server Error I do make that mistake quite often!
- iab 5y agoInadvertently insightful
- louissan 5y agoerror 500 xD
- deleted 5y ago[deleted]
- sdoering 5y agoI 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 5y agoThe 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.
- danielmarkbruce 5y agoIf 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.
- sdoering 5y agoI 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.
- strict9 5y agoInsightful 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 5y agoI'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 5y agoSome 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.
- 24thofjan 5y agoI'm curious about Zach's thoughts on how to use Github. Merge or rebase?
- davidhyde 5y ago> "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.
- abofh 5y agoYou 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
- cercatrova 5y agoThe 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 5y agoSure.
- jackblemming 5y agoWhy 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 5y agowe are probably hiding the work and not looping in those mentioned precisely because it gets shut down
- jackblemming 5y agoThat’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.
- JamesBarney 5y ago> 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-are-tracer-bullets https://builtin.com/software-engineering-perspectives/what-a...
- irrational 5y ago> 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.
- salt-thrower 5y agoI 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 5y agoExactly. 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.
- leeoniya 5y agoit 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.
- Trasmatta 5y agoI'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.
- mattferderer 5y agoAs 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 5y agoAgreed, 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 5y ago
- pphysch 5y agoThere'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 5y agoI 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 5y agoSorry, 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 5y agoWhoops perft() sorry.
- taurusnoises 5y agoNot 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.
- 3pt14159 5y agoThis 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 5y agoI 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.
- 3pt14159 5y agoYes, exactly. Again, if you have a good team though, they'll trust you to do the right thing from the get-go because they know you got their back.
- TameAntelope 5y ago
- adverbly 5y agoThey 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 5y agoIt 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.)
- alokedesai 5y agoI work at Warp (https://www.warp.dev/ 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.
- mberning 5y agoSpending 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.
- Ensorceled 5y agoI 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 5y agoWhat'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 5y agoProduct Requirements Document ... a full specification of everything the software needs to do. Sometimes VERY detailed, sometimes not so much.
- TameAntelope 5y agoThey could probably just write this in code, and save a lot of time.
- watwut 5y ago> Caveat ... truly stuck ... tried a couple of things, googled, tried some more ... wondering what to try next. That is not even possible within 5 minutes. I would not want to work there honestly. Just being unable to solve problems demotivates me. It sounds like I will get off everytime I am slightly slower to pick something. This would be too stressful for me.
- AtlasBarfed 5y agoWhen 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.
- Veuxdo 5y agoSometimes 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 5y agoIndeed, question made by managers is: “Can you train in spare time?” “While working on your own projects”
- gorgoiler 5y agoSolid 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.
- babycake 5y agoTo 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 5y ago> 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.
- pojzon 5y agoI’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 5y agoAmen 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.
- pojzon 5y ago> It might actually be a structural or cultural problem in the organization. It's indeed often a structural and cultural problem. I'm yet to see some organization to turn that around.
- throwaway71683 5y agoThis reminds me of a coworker that I've had bad experiences with. He fancies himself an architect, but he consistently refuses to accept any feedback on his designs. If we give feedback early in the process, he complains that we're nitpicking an incomplete design. If we give feedback when he deigns it completely ready for our review, he complains that he'll have to throw away so much work. All throughout, his refrain is that we "just don't understand his design". I agree that it's harder when there's an absence of peers at the same experience level, and for problems that can be completed by one person, it's probably not necessary to seek validation. But if it's a problem that requires a team effort, building shared understanding of the design is at least as important as creating the design in the first place. Yes, it's more work if it doesn't click immediately for everyone else, but it's essential. And sometimes in the process of explaining it so that even a "not great" engineer can get it, we can better understand it ourselves. And sometimes even a layperson can bring valuable insights once they get the gist of it.
- Ozzie_osman 5y agoWe 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.
- elric 5y agoKnowing 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.
- kinakin 5y agoWe 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 5y agoI'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.
- throwaway889900 5y agoMy experience has been "Get stuck, avoid the senior engineer because they have no bloody clue what's going on and talking to them actively makes things worse for months afterwards".
- escapedmoose 5y agoBut I don’t wanna talk to the other kids. :I
- zoomablemind 5y agoThe 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.
- deleted 5y ago[deleted]
- quickthrower2 5y agoOne 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!
- xbar 5y agoThis is really good, but I feel like you should have come to us with this topic sooner.
- markus_zhang 5y agoActually, if we turn the perspective and look through the developer's eyes, the behavior makes a lot of sense.
- duxup 5y agoSometimes it is really hard to know that you've been out in the weeds for a while until you're there.
- aetherspawn 5y agoI 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.
- PaulHoule 5y agoI'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.
- retinaros 5y agoyeah. 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
- sytse 5y agoGitLab our iteration value https://about.gitlab.com/handbook/values/#iteration https://about.gitlab.com/handbook/values/#iteration is meant to address exactly this problem
- TameAntelope 5y agoI'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/ https://blog.codinghorror.com/dont-go-dark/
- stephenboyd 5y agoI 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.
- bob1029 5y agoI 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 5y agoI 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.
- kerneloftruth 5y ago"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 5y agoProof to whom? Shouldn't you be developing things your customers need, not some pet project you enjoy working on for its own sake?
- jlokier 5y agoProof to whoever the stakeholders are, presumably the customers in your model. Proof that it satisfies what the customer needs or wants - something which can't be demonstrated until the would-be solution reaches some level of demonstrable maturity. For many engineering solutions, you can talk about them earlier, handwave, present, but nothing conveys that it actually works, or sometimes even makes sense, short of a working demonstration. Why so quick to assume it's a "pet" project? If the developer is doing it right, they are making exactly what the customer needs, but the customer does not have the developer's expertise to recognise what will work at an early stage. We are not talking about things everyone understands and could have an opinion on, like say the colour and layout of the login window. Take something that requires deeper work and hired expertise. For example suppose you've started to design a new kind of GPU technique that will double the customer's calculation throughput for the same power consumption. They hired you for your expertise to solve that sort of problem. They have no idea how it works though, and for the first month you have only an outline of a new algorithm, that only peers at your own level could understand well - and you don't have any peers in that area. And most of figuring out the details is on paper and whiteboards, math and logic along with throwaway experiments to measure. The first line of code in a working demo is not possible to figure out until 3 weeks in, and it takes only 1 day of coding and 2 days of polish after that to finish. That sort of thing isn't a pet project. It might not even be fun; it might be quite stressful, after all it's a higher risk to the developer to pursue such paths. It doesn't fit into daily PRs and isn't even a coding problem at first. Yet it's exactly what the customer needs, what they said they hired you to accomplish, and what they will appreciate if it has reached the point of "proof" when shown. It will be incorrectly assumed to be the developer's pet project if it's demonstrated before it works, though. Thus the reason to build it up to "proof" level, if you're sure the customer needs it.
- blindmute 5y agoI'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 5y agoThat'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 5y agoThe 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.
- commandlinefan 5y agoThis 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.
- DoingIsLearning 5y agoI suppose 'know your audience' applies here. Generally the higher up the food chain the less likely that people will 'get it' if it is not an extremely polished Proof-of-Concept (there are exceptions of course). If I am going to play amateur psychology, I would say that people who are generally more perfectionist types and are likely get caught up in details are less likely to give a healthy review on work-in-progress.
- emptybottle 5y agoMy 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 5y agoI think that’s just because it’s too much work to review so people give up
- schrodera 5y agoGoing 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.
- emptysongglass 5y agoThe 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 https://sahillavingia.com/work
- thrower123 5y agoI'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.
- heisenbit 5y agoWhile 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 .
- xtat 5y agoOk advice for engineers who are following orders but definitely an anti pattern for creativity and innovation.
- strictfp 5y agoA few things; 1. Merging often and early might be viable, but it might also expose your colleagues and the codebase to your exploratory process, which might or might not be desired/possible. If you're making semi-permanent changes like API modifications or database table updates, going this route will mean a lot of extra work. 2. Too many chefs. If you open up for too many questions at the start, you will get a gazillion conflicting opinions thrown at you. You'll need to limit the audience somehow, or bring forward a clear idea or opinion. This leads to developers working a bit on the side. I don't mind this, I think it's good to give autonomy to working groups and let them make mistakes, as long as there is coaching or feedback in place in the long run. 3. If you go the route of designing a bit on the side first, to save time compared to 1), you might suddenly find yourself in the situation that the major parts feel quite done. Adding polish is now just a minor addition to what you're already accomplished, so you might do that before putting up the PR. This means that a complete solution showing up as a PR doesn't necessarily mean that it was over-engineered or overly polished on the side. 4. Not "syncing" too often saves time; less context switching, distracting information, and time to reflect on decisions and design.
- babbledabbler 5y agoIt's usually a mistake to build a large scale solution without consulting with others in your organization or team. Other engineers often have good feedback that will make your solution better and you are likely missing some core premise or context. It's also a mistake to seek too much approval from others before proceeding. In any group of X people, Y% won't agree with you, and of those, Z% will be uncivil. By uncivil, I mean harsh criticism or otherwise toxic behavior that is not constructive. If the organization is healthy that Z% is small and troublemakers will be handled by management if they do act up. If not that Z% will basically become like bridge trolls and you will be opposed by a confederacy of dunces every time you try to do something of consequence. I've experienced both of these scenarios, and striking the right balance is an art and a science that boils down to reading the politics of the place and getting buy in from some key people so that your project at least has a fair shot. Sometimes the place has gone toxic and it simply can't be helped. If you're in a situation where there is a high percentage of Z, you should ask yourself if the work you are doing is worth playing the politics necessary in order to get the job done. If yes, get smart, read books like the The Prince and Art of War and figure out how to play the game. If not, get outta there as expeditiously as possible, and put your time and effort to something more worthwhile. If you want to be kind, let management know in a professional way exactly why you are leaving so that they can have an opportunity to try to make life better for your colleagues.
- drewcoo 5y agoIt's about career growth. Most programmers (hope to) peak there. You know those folks who peaked in high school? You look at them and feel sorry because that was as good as it got for them but tinged with a hefty dose of jealousy because you never had it that good then. This is like that but in software terms. An individual contributor mostly works up to the point where they take on more than they can handle alone and are sometimes heroic. And some people, some really good ones, peak there. The crazy debugging live on production servers in the middle of the night that saved millions of dollars or the championship-winning touchdown. Same same. We love to tell those stories.
- blintz 5y agoI 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.
- deleted 5y ago[deleted]
- LAC-Tech 5y agoI've got the opposite issue, and if I'm being frank - maybe it's not such a great look for me as a senior. But also at the same time... why should we suffer alone? Sometimes something that might take you a day by yourself might take you an hour with another person with a fresh perspective. Isn't it more efficient? Let's loop each other in, often. I'm always down to share screen. Unless of course I'm the only one oh God I've outed myself as useless on HN...
- mjrbrennan 5y agoDon’t worry you’re not alone! Sometimes I worry about the same thing too. But ultimately I think it’s dumb to struggle along with something for days or working on something that no one actually wants or is going in the wrong direction for days. Much better to just loop others in early and often so things are done right the first time, and in the most effective way possible.
- lifeisstillgood 5y agoA late comment I know but one I just realised is important. This whole article bothered me. And the realisation is that it expects upfront design to work as something distinct from coding. "The code is the design" (Jack Reeves) is a fundamental point - until you write the code, you are just dealing with "artist's impressions" - vague ideas that might not hang together. The code has to be written (to be thrown away) so that things can be really worked out. Other points: * everyone does not have time to be always commenting on everyone elses iterations. Yes there is time for the big architectural design. But every day? If I am commenting on some other engineers work daily and not actually working with them something is off. * going off and coming back with a big PR. YEs thats bad. Going off and coming back with a Proof Of Concept that will inform the discussion. Thats good. With a Big System, the right way to do it is to do one (at least) to throw away.
- globalise83 5y agoI heard it put best as "Don't polish a turd".
- trelane 5y agoInterestingly, I just realized another sphere where this occurs: management. A manager sees some perceived problem, comes up with a policy to "solve" it, and then requires their employees to follow the new policy. Wonder what this sort of approach would look like for management. It seems like the employees are the "customers" in this arrangement.
- samjewell 5y agoI'm amazed that the author doesn't recommend Pair-programming as one of the techniques to avoid "Doing too much before looping in others" He mentions: > an engineer on a project should never go more than a week without showing something, and usually it should be more like a day But in my experience by pairing you can shorten this feedback loop to seconds. A few other people have commented about pairing: It's clear people have different preferences and that it's wise to use pairing at the right moments, but it still seems a glaring omission from the article to me.
- black_13 5y agoI dont like working with others or rather when I sought out others help I was seen as an impediment to the 10 percent performer. Most organizations reward and the individual scale not group when you tried to work communally you were chastised or all the way punished.