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

https://archive.is/ZFwUh

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.

> "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.

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.

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.

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

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).

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.

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.

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.

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.

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.

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.

A 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.

It'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.

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.

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.

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.

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.

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

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

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

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.

"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.

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.

A 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.

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.

> Internal Server Error

I do make that mistake quite often!

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.

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 .

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.

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

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.

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.

> 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...

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.

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.

Ok advice for engineers who are following orders but definitely an anti pattern for creativity and innovation.

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.

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/

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.

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!

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.

It'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.

I'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.

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!

I'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...

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.

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?

Interestingly, 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.

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.

I 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.

I 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.

GitLab our iteration value https://about.gitlab.com/handbook/values/#iteration is meant to address exactly this problem

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.

This is really good, but I feel like you should have come to us with this topic sooner.

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.

> 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.

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.

Actually, if we turn the perspective and look through the developer's eyes, the behavior makes a lot of sense.

Sometimes it is really hard to know that you've been out in the weeds for a while until you're there.

working on the issue with the site going down. more traffic than i expected...

I heard it put best as "Don't polish a turd".

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

But I don’t wanna talk to the other kids. :I

error 500 xD

> the biggest mistake I see engineers make is doing too much work on their own before looping in others.

I'm curious about Zach's thoughts on how to use Github. Merge or rebase?

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.

Why the conflation of 'engineer' and 'developer'? That's a bit confusing.