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.
This resonates with me. I think we do our best work when we have the autonomy to apply our expertise.
But at the end of the day, you're not the only one writing that novel. If you have an idea of where the plot is going but your teammates think it's heading somewhere else, it's going to be very problematic.
The other problem is that you _will_ make mistakes. Some could be avoided by leveraging the experience of your teammates. You also won't always strictly have the best ideas. Brainstorming as a group can be a lot more effective than sitting alone for a long time thinking hard about a problem (but also sometimes hard problems need a lot of individual thought).
I suppose my point is that I'm not sure where the happy medium is? I've been on both sides of the "engineer working too long alone before sharing" problem and I think it sucks.
How do we enable engineers to do their best work but also allow our teams to be successful?
We don't all have to agree on everything. I think that's a fallacy.
I'm going through exactly this at the moment. For reasons HN will probably consider fiction, my superiors have started treating me as a toddler that needs oversight on every single decision that needs to be made.
It's something I've been dealing with in therapy, and the way I was able to explain it to her was by saying that I feel like the monkey in the infinite monkey theorem. Never thinking about what you're producing (if you can call it producing at all), just pressing buttons.
It makes me wonder what the point of having me even is, considering they spend so much time solving all my problems for me. I've come really close to saying "ok, go ahead and let me know when it's done" during 40 minute meetings where every minute detail of what I'm supposed to do is discussed by 3 people.
I guess there's a reason the phrase "code monkey" exists. Jonathan Coulton said it pretty well:
Code Monkey have boring meeting
With boring manager Rob
Rob say Code Monkey very diligent
But his output stink
His code not “functional” or “elegant”
What do Code Monkey think?
Code Monkey think maybe manager want to write god damned login page himself
One reason they do this is usually around control. A lot of people feel like they have to be in control of everything in order to be safe. There may be ways you can make them feel safe without needing them to be in control.
Another reason is that until the thing is built, there's nothing to do, so everyone gets involved in that. This happens a lot in startups where they have a "build it and they will come" attitude. It's not true; building a sales/marketing channel doesn't actually need a product at the start, and there's a ton of stuff that needs doing while the product is being built. But it can be difficult explaining this to new founders.
Good luck :)
I guess the next step for me is to figure out how to avoid going into such situations (I entered the situation because I was joining a team in an area that I wasn't familiar with and decided to work on an existing project whose owner has a very strong presence and I didn't clarify the specific work item / boundaries clearly in the beginning).
This issue largely disappears if your engineers are given the proper context, background and system overview.
I'm not advocating everybody should take their project and run with it for weeks on end, but daily updates are ridiculous.
In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to 16 hours of work.
If you can't work at that cadence, you're probably not being as effective as you could be, as a developer. A "good" manager enables you to work like this.
Obviously there are limits to this approach and it wouldn't work well for solving really difficult problems, but really, 99% of day-to-day development work isn't that special. A motivated and conscientious developer with average skills can get an awful lot done with minimal distractions.
From my experience, people don't actually want to control the output of everything, they just want the opportunity to be heard. What you do with it from there doesn't matter as much, so long as the desired outcome is "correct". If the desired outcome is not correct however... then you have to justify all of the input that you didn't act on.
But regardless, I find that whole process exhausting and disempowering, even if there is sometimes a benefit from it.
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.
In bad teams I end up defending myself from people who want to leave their mark on what I'm doing, or just have different taste than me. Getting feedback in these situations is frustrating and demoralizing.
I wrote a program the way I think it should be. Clean code, super easy to understand, super low complexity. Anyone can understand what it does.
Thats fun for me, when the code is very simple, reads like English and there are no complex functions.
I don't do real software engineering however (just business intelligence and python programs to extract and load data). But when it comes to looping in colleagues, I avoid it for the same reasons as above.
Its exhausting.
I believe this is why books most often have a single author. A solution to this, is to agree on the global design, and then have different developers own different "modules" of the design. These modules should be treated like third-party libraries (and should act like third-party libraries vis-a-vis of their documentation and API).
Basically, microservices can exist within your code if you know how to modularize well.
... And at least one editor, no?
I use this exact description when discussing balancing creative side of the value creation project processes, design and development over the value extraction side of products. Small empowered teams with an almost startup mindset is key, but even more is time to play to find solutions that can make products that are more like friends than enemies to people.
Engineering/development, creative and product design/development are creative fields, a value creation action and activity.
Business, finance, marketing do not see many parts of this as a creative action but a production line, a value extraction action and activity.
A large problem is the misunderstanding that new projects are value creation not just value extraction, and rely on creativity at inception. Once they are established they can be more patterned and predictable and ramped up, but initially the creative phase is the key to making good products. Smaller teams, more empowering of the people that can create products that get the early points right. Taking long enough in the "open" mode before the "closed" mode is key, essentially prototyping and play is needed, but rarely available in the modern processes and project management systems where engineering is simply "production". There is a pre-production and post-production that is usually left out.
For instance in game development, pushing through a project process before the main game mechanic is "fun" is a problem. You can't get creative on a forced schedule just as you couldn't write a book that way or come up with a novel new concept in some software app that should be a friend to users. The prototype of the project or product must have some time to simmer and iterate on. The first thing managers do is cut that time and sometimes throw too many people at it resulting in Mythical Man Month level mistakes leading to too many cooks. When a prototype or early product has value mostly figured out, then it can go into a more robust process to create variations or iterations. The initial value creation will always be wildly hard to estimate.
Good examples of this in software are programming languages, usually it is one person for a long time then others join in to ramp up when the vibe of the language is set. Same with books, movies, games, anything really. You can't have 10 people drawing the same illustration or writing the same book, the parallel part can be multiple people doing their own to see which is best, but you can't have them all in on one creative project without it being confused.
I have seen companies turn into faction based wars when varying groups don't clearly respect the value creation and value extraction balance, the value creation MUST come before the value extraction. The open mode before the closed mode.
A great talk by John Cleese on the "open" and "closed" mode [1] helps describe this, which I recommend and hope everyone I work with watches. Value creators need time and creativity to create value both in the "open" mode to explore/prototype/build and the "closed" mode when things are decided to ship. The value extractors always want people in the controlled "closed" mode only, the "open" mode is non quantifiable and seen as almost an enemy to the value extractors but is key to creating products that are so good they are like friends to value creators and the people using the products.
The value extractors are who Fred Brooks talked about in the Mythical Man month [2], they think things are a factory with already figured out steps, when you are in a field that uses originality, creativity, the mind over the physical, it isn't like a factory or supply line. Every single project manager needs to know about the Mythical Man month.
Here's a great point by Steve Jobs about product stagnation and the managers/business side [3] and how they can run amok if not controlled to allow value creation to continue, and how monopolies or problems that arise when only the business/managers are in charge. This point is more about larger companies than new projects but the same forces that stop innovation at large companies also kill it in any sized companies when there is no value creation / value extraction balance.
> It turns out the same thing can happen in technology companies that get monopolies, like IBM or Xerox. If you were a product person at IBM or Xerox, so you make a better copier or computer. So what? When you have monopoly market share, the company's not any more successful.
> So the people that can make the company more successful are sales and marketing people, and they end up running the companies. And the product people get driven out of the decision making forums, and the companies forget what it means to make great products. The product sensibility and the product genius that brought them to that monopolistic position gets rotted out by people running these companies that have no conception of a good product versus a bad product.
> They have no conception of the craftsmanship that's required to take a good idea and turn it into a good product. And they really have no feeling in their hearts, usually, about wanting to really help the customers.
Modern project management processes promote shallow change over deeper dives. They create a risk profile for anyone looking to bring new innovations that might be hard to estimate because it will be a perceptual hit. These rigid tightly wound processes are horrible for creativity. Agile itself has been captured with tightly wound controlling mechanisms like the daily standup, and so much weight around trying new things as well as perceptual hits for that. Anyone truly trying to make new value will be seen as an enemy to these systems. Agile was created to give product people more margin to build, but it has been coopted into being used to control creativity which cannot be controlled, it simply disappears when there is no open mode and only a closed mode or nothing but value extraction.
All of this is spelled out in "How Software Companies Die" as well [4]. I wonder when if these realities will make it into the business education curriculum.
[1] https://www.youtube.com/watch?v=Pb5oIIPO62g
[2] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
[3] https://www.businessinsider.com/steve-jobs-on-why-innovation...
In my team we always publish some form of status report at the end of the day. This could be a pull request or a list of open questions on the task. For us that is less about micro management and more about bus factor: If a person calls in sick the next day the rest of the team wouldn't be able to continue that persons tasks without this process.
I understand that this can be detrimental when it feels like micro management. But I believe it is more a question of framing.
Depends what "showing" means - on the other end is doing all prototyping/exploration as pair programming - thus immediately "showing" work to at least one other engineer.
> "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.
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
Ha! Yeah, I worked on a really cool project for a charity a few years ago: "How many hours is this going to cost us this week, you were working like a warrior?" "35"
Lawyers must hate their work.
From my point of view as both a programmer and an employer, this is the cleanest way to make sure knowledge transfers between short-term and long-term team members.
Why the disdain? (If I interpreted correctly.)
In what organisation do 25 year olds manage 50 year olds?
This is one of the more toxic ones. To get past senior, you often need to be seen to do Big Memorable Things. It sometimes leads to perverse incentives.
I am incredibly fortunate to work in a place that values ownership, both explicitly and in practice. Given how widespread the opposing value system is, I'm afraid to ever leave.
This can mean a ton of things, which cannot all be served by a single senior+ engineer:
* mentorship
* seeking out, establishing, and evangelizing best practices, and not just coding best practices: architecture, documentation, testing, ci/cd etc
* high-level architecture knowledge and experience
* evaluating technology choices: tooling, databases, orchestration platforms, etc etc
* assisting management and product with scoping and prioritizing work
* the ability to put your head down and crank out a solution to something in code simply because it needs done and you can do it better and/or faster than others
* laying the framework of a greenfield project, maybe sketching out the codebase or POC for juniors to take and run with
* ...and so on and so forth.
A single person may be able to contribute all these things to a team over a time frame of multiple years, but in a 3 or 6 month time frame, most mortal engineers could only contribute two or three.
I think a lot of people have weaker communication skills than execution skills. So they could loop in everyone early on, but their idea might get killed off because they failed to justify it properly. If instead they leverage their execution skills and make an MVP that will speak for itself, then they bypass that issue.
Taking chance to do a bit of focused work and actually do it in that environment is not toxic. It is not like you have run of for months and refused to communicate. It is just ... getting slight bit of rest.
The other thing that can encourage doing too much work before looping in others is the culture of the team. You are lucky if you can amass a team of people who all have the same attitude of talking to each other frequently and handling a certain level of interruption. I've worked on such teams and miss them. Although pretty much everyone at any company you work at will say "ask questions, don't hesitate, blah blah blah", there are teams where people go weeks not talking or sharing work, and everyone is always too busy to get interrupted. If work gets assigned in large chunks, as can happen for seniors in particular, it can also just not make sense to loop in someone temporarily if more time needs to be taken for the other person to catch up.
I like writing code. I dislike talking to people.
Or your organization relies on "consensus" or "influence" to get any project done, and one of the groups (which don't share managers back to the ceo) doesn't want to do the project even though the others think it is important. So do you spend months trying to convince them while doing nothing promotion-worthy in your own?
i do think giving space for hard work is important. i still more often see the opposite problem of too much silo'd work leads to wasted effort, but for some really hard problems, having a bunch of space to think them through is beneficial.
This is just another way of saying "management is right, even when they're wrong, and you need to accept that".
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.
... 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.
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.
When juxtaposed to manager, it usually means individual contributor - someone being managed rather than doing the management.
> 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.
[1] https://courses.csail.mit.edu/6.803/pdf/hubbard1899.pdf which is both historically apocryphal and only good advice when dealing with an impatient and incurious leader.
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.
Also I learned a lot from my boss' refactorings. Before that I never would have imagined how far a good abstraction can be driven.
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.
If there are no tests, the team will waste a ton of time anxiously monitoring and reasoning about the messy code and the impact of their changes.
This way I'm able to quickly and confidently refactor as well as add to existing tracking code (web analytics).
It's very easy to get stuck in design hell and write yourself into a corner. It's much better to get something that does what you want, then you change it to do it how you want it to.
Though like others have mentioned, this requires an engineering culture that values the second part.
But essentially I agree with you, good writers use the same technique: write once, revise many times.
Good code, IMO, only exist after many refactors.
I don't usually pick an absolute, decisive side in the "what counts as engineering" debate, but this is the opposite of engineering.
Also some people feel the need to tightly control group chat. Either content (no "offtopic"), membership, or # of rooms. Some chat platforms encourage this by restricting who can create/manage rooms or how rooms are linked together (discoverability).
It's an unexplored area of knowledge for most people in the new WFH life everyone's leading.
But the job pays well and has interesting problems to solve, so I guess I will put up with it for some time more.
> It can also happen if the team culture is toxic and engineers fear getting criticism early in the design process.
I think the author would agree with you.
At least the business side of the house appreciates the spec'd work being accomplished.
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".
There are distinct educational programs that differ between "computer science" and "software engineering", and a number of professional organizations are lobbying for software engineering licensure, similar to other engineering professions.
Even Dijkstra knew of the differentation: '"A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."'
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 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.
It's indeed often a structural and cultural problem. I'm yet to see some organization to turn that around.
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.
Example. You discuss different ways of data replication and have to decide which suits the project the best.
Issue is only you have experience with multi-region data replication and people you discuss the issue with dont even understand how replication works.
From manager point of view -> you were hired to guide those ppl.
Thats what happens in consulting like 99% of the time. You are the part of the team but you are often expected to provide the solution.
You can “explain” how it will work, but 9/10 times you wont get any feedback because ppl that you are supposed to deliver that project with simply dont have the knowledge required to have a good level of discussion.
Its like saying “PHD Doctors should have even field discussion with anti-vaccers, because both of them have something to say”..
Everyone has something to say, whether its something valuable, its a different matter.
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.
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.
Sometimes VERY detailed, sometimes not so much.
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.
Why would you want to be sitting there spinning your wheels? Most people find that feeling of helplessness demotivating and stressful which is why I created the rule.
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.
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.
Also, at larger companies your manager tends to reorg. I've gone through 5 managers in a single year before. And with them goes all the goodwill you built up during that time. New manager comes in, and it basically resets your 'perception' factor. The old manager might tell the new manager that some people are good, but you have to get lucky to get the new manager to care, because they haven't seen the results with their own eyes yet. That small time window is when it's ripe for someone to swoop in and claim ownerships of projects, while smooching up to the new manager. That's what happened with the senior dev I saw, but he had aces up his sleeves. What an epic showdown.
Yea, I should leave probably, but it's just one burning ship to another. That's our fundamental reality.
The more organization separates project implementation from the goal-setting and strategic work, the less reasons are there for people responsible for implementation to focus on something different than just getting another green checkmark on that project milestone (and getting recognized as the one who was most impactful in getting there).
Sustainability, recognition of actual business value, meaningful team work — all of these quickly go out the window as people focus on gaming the only metric they’ve been assigned.
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.
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.
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.
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.
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.
>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.
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.
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.
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.
(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.)
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.
> 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.
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.
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.
“Can you train in spare time?”
“While working on your own projects”
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.
I do make that mistake quite often!
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.
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...
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.
Can we edit the title to remove these kinds of clickbaity titles?
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.
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).
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 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.
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.
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 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.
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.
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.
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.
Of course doing a submarine dive for weeks is never good except to serve as a straw-man for a blog post .
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.
Pragmatic programmer called this a "tracer bullet".
https://builtin.com/software-engineering-perspectives/what-a...
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.
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.
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.
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.
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.
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!
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.
Wonder what this sort of approach would look like for management. It seems like the employees are the "customers" in this arrangement.
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.
Going dark as a team is a different story.
so I guess id rather do too much work before looping in others
