The absolute best technical person is a meld of these two.
Pure pioneers look like the fabled "10x programmer" on the outside, but leave a hellscape of technical debt in their wake.
Pure process people are so busy building their perfect ivory tower they miss the actual goal of getting stuff done.
Somewhere in the middle, where you've figured out how to move fast but also avoid causing the tech debt you've encountered in the past is the right place to be.
This usually boils down to having good boilerplate when you start something - for code, that might be a trivial but well understood linting and testing framework that you can add at the start of a project, or a simple way to start documenting a business process.
> Pure pioneers look like the fabled "10x programmer" on the outside, but leave a hellscape of technical debt in their wake.
"I've made the MVP"
"Ok, let's have a look... uh, if any of five remote servers so much as sneezes, this service will crap itself and die"
"It's fine, it'll restart itself after a few seconds thanks to some aws magic"
"And any ongoing transactions?"
"Details, whatever..."
I also think there's a middle ground. I see myself as the pioneer type, but you have to start building a semi-solid base, not just throw stuff together at random. I've seen a number of 'pioneer' folks who just throw together the sloppiest thing ever and move on. Hopefully the article writer isn't one of those...
As an aside I wonder if almost everyone would prefer to be the pioneer, but ends up getting stuck in process-land and maintenance hell.
I mean it depends on the context. I've built the mvp version my startup in a few weeks of not sleeping, doing a hundred things the wrong way [1]. But the goal was not to build a proper system, but to build something to prove there's a need for that, which allowed us to raise money and fix the issues later.
And I'm still having trouble explaining to our engineers that sometimes it's okay to accrue tech debt if it serves a business purpose. We can have the most technically sound product but if the money runs out the game is over. Startups are a crazy sprint, not a well paced marathon.
The problem is if the tech debt is not a conscious decision you're making
> We can have the most technically sound product but if the money runs out the game is over.
I think most engineers are just not used to ever thinking about time and money as a constraint - they're just things abstracted away from them so they can do good work (or they've worked for companies where those aren't constraints). Just being up front with them about the fact that these constraints exist will usually change how they think about a problem (in my experience at least).
> The problem is if the tech debt is not a conscious decision you're making
100%. The entire debt metaphor fails if you aren't knowingly doing something that you're going to have to "pay off" later.
It usually takes several of these conversations for them to start thinking like that.
Why it works in our case is because I acknowledge it's a debt and then later we pay it back. A huge problem devs have is - there is a push, promises are made, and then something new and urgent comes along.
I do agree, most devs usually work in large companies where money and salary is an abstract thing several layers removed from them.
When I was a developer I used to despise some of the places I worked at, but now when I'm trying to start a company I see them in a much different light and see that a lot of things made sense
Oh agreed, it's a lesson to learn, just like the rest of their engineering practices were learned. You don't usually absorb stuff like that fully by having someone tell you once.
> Why it works in our case is because I acknowledge it's a debt and then later we pay it back. A huge problem devs have is - there is a push, promises are made, and then something new and urgent comes along.
I don't think it works any other way. A lot of times the only difference between "intentionally accrued tech debt" and "shoddy work"/"bugs"/"brittleness"/etc is communication.
> A huge problem devs have is - there is a push, promises are made, and then something new and urgent comes along.
If you're constrained by time and money, this is usually the case. You accrue tech debt to meet constraints, and you pay it off over time, not necessarily immediately. It's just normal roadmap prioritization. All you can do as an engineering leader is correctly advocate for the urgency of tech debt, communicate interdependency issues ("we must pay down this tech debt before we can tackle feature X"), and pay off some debt when it makes the most sense.
That's why for me it always comes down to leadership. At least in Europe, which doesn't really understand software, developers are put under management of people that do not understand the craft at all.
I personally hate the fact that agile, which started off as a couple people saying "we're all professionals and grownups here, let's talk regularly about how to combine this abstract thing we do with actual client needs" is now a whole industry.
There's now a whole profession of "scrum masters", most of whom haven't the first clue how to actually do anything much, and none of whom are needed - the scrum master was just the guy coordinating, a monor extra duty that could even rotate. But no, we have people hanging on to our industry, claiming to add value, who spend their days fussing over jira... it's a tragedy.
I agree - but also technical isn't important at that phase, business value is. And often technical architecture needs change as product fit, market fit change.
I think the split makes more sense as process versus "heroes" (which is an old view I used to hear at process training classes). Rather than depend on key people able to solve any problem via "heroic" efforts (e.g. all-nighters or long weekends where they rewrite everything or learn an entirely new skill), you follow a reasonably-intelligent but slower process that has worked historically and can make progress even with average contributors.
Management of course loves (perhaps even needs) to make a commodity of employee skills, so process is always pushed early and often. But even the heroes will get burned out or reach a point where the product is just too big to handle otherwise.
> you follow a reasonably-intelligent but slower process
To my knowledge, few early-stage start-up succeeds this way. It's great to think we can make up for the pioneer-style solo contributors with any army of process IC's but I have yet to see that happen during the early years. You can just look at any current tech company and see that's the case - all of them had pioneers at the beginning that pushed forward incredible progress. Google, Microsoft, Intel, Cisco, Sun, SGI, Facebook are just some recent examples that come to mind.
I can certainly believe that's true because opportunities which can be solved by top-down process-driven progress can be addressed by market leaders and leave little opportunity for startups. Though I don't know that a sample of superstar companies makes for a definitive dataset. I know of multiple companies no one has ever heard of who are dominating their niches (that no one cares about, until you hear how much money they are making), and the most important factor to me looks like risk-taking, good positioning, and good timing by the leadership, not anything special in terms of technical achievements or flexibility by employees.
Alternatively, build a team with a mix. Sometimes having a person passionate about process can be very helpful when they have a little tension with the pioneer types.
They drove me a little crazy, but one of the best people I ever worked with was a “test enthusiast” and believed that anything not automated was going to eventually cause us trouble.
It was good friction and made one helluva a system that managed to serve a couple hundred thousand remote clients while basically on autopilot for several years now.
For sure. It means you actually have to be intentional about what you test. Best team I ever worked on had two loud, friendly, utterly opposite engineers when it came to excellence vs velocity. But it made us really talk through why we chose the things we did.
A team with a mix is best if it's not a mix just in terms of personnels but in projects and the way incentives are structured.
The culture within the team can go south sooner than one realizes if the 'process' types feel they're constantly cleaning up the mess of pioneers (who tend to get more attention in general for their shinny projects). And on the other hand the pioneers may perceive process-types folks resist any new changes and are stuck supporting outdated technology. The truth usually lies somewhere in the middle.
I've found this to work extremely well. I tend to err on the side of caution, building well tested systems with carefully planned failure modes. I work very well with people who drive hard and spit out a ton of rapid prototype code that's full of bugs. It's frustrating, and there's often tension. But the end result is the best of both worlds.
Maybe don't, they keep the world from falling apart at its duct-taped seams.
You aren't giving us enough context to know whether that changelog requirement is a good one or not. But if your team has agreed on the process, either convince them to change the process, or try to understand why your (hopefully reasonable and competent) colleagues believe it's necessary.
> what if your team is dominated by process people.
If that's not your jam, consider a new job.
> only explanation that everyone agreed to was that "it makes it easier to see what changed"
Maybe it's safety critical software or there are downstream clients? Maybe it's open source? Maybe it's not actually every PR and we have an unreliable narrator? The post did start with "I hate process people", after all.
For what it's worth, I'm notoriously not a process person. But I've seen and respect stability they can bring to a team and product
fwiw way back i used not see the point of changelogs, but after experiencing what it's like to consume a lib or use software without one, also how useful they can be when you need to know what's changed, it i've changed my view on them.
I’m not sure I accept the distinction. For the amount that the concept gets bandied around, there’s actually very little evidence that people fall into discrete personality types like these.
We are all stronger and more experienced in some areas than others, but simply writing yourself off as ‘Not a process person’ removes your ability to level up and takes away your ability to do any better.
It’s especially sad as these ‘scripts’ often do not come from inside, but are baked into people from leadership and then justified by Myers Briggs style psychobabble.
I like the distinction between pioneer, settler, and city planner when thinking of the people working on new products. To me, it’s more about the lifecycle of a product as opposed to putting people into boxes.
I feel like I know what business/code trade-offs I should make depending on which of those characters I’m currently playing. I also know what type of flexibility I should build into the product early on and which best practices can wait until market fit has been found.
I wouldn’t want to take a city planner into the wilderness (sewers and squares before we know if anyone wants to even live here, lots of high quality code that has no users). And I also wouldn’t want to be a mayor having pioneers running my subway/water system (bandaid fixes, poor long-term decisions, spaghetti code)
But I agree with you overall that people can adopt these roles based on context and aren’t limited by them
Over the course of 35 years developing software, I completed several circuits of pioneer/settler/planner loop. Learning to function well in all three domains was as important to increasing my professional value as learning different languages, tools, OS's, and problem domains.
I think you're looking at it from the wrong angle. It's not about typecasting a individual person. It's about recognizing that there are these divisions in the work that's available. It's a feature of the environment, and you should recognize it and your relationship with it.
Then you can be aware, for your own good, of where your preferences and strengths lie, and make conscious decisions about what to take on, whether working on your core competencies is wallowing or increasing your depth; whether a stretch would constitute "levelling up" or just stress.
(Incidentally, in response to your swipe at Meyers-Briggs, the same is true there: it's a tool to help you recognize your own inclinations and be aware of them so that you can grow meaningfully and purposefully. It's not for boxing yourself in and saying, "I can't/shouldn't do that because I'm an ABCD".)
People do treat these as binary typecasting instead of shifting scales. On the leadership side, it means that they will treat as immutable personality type something that may be just reaction to the position you are in.
And once you self-identify as pioneer (because it sounds cool) you just become more of pioneer and prevent yourself advantages of process (or vice versa).
That is similar to the same problem as with Meyer-Briggs - most people are in the middle of all scales and their result shift over time. Those in the extreme end are rare. But both extreme and and middle get the same type description.
And you end up inflexibly casted in one group although you are more similar to people in different groups that are also in the center then to extremes of own group.
> writing yourself off as ‘Not a process person’ removes your ability to level up and takes away your ability to do any better.
I've worked at places with varying levels of process. I don't get enjoyment or fulfillment from following a process, defining processes for others to follow, or from enforcing process on others.
When I have choices, I would rather be paid to do things I enjoy and let me feel fullfillment than working at a job where I have to spend a lot of time doing stuff I don't enjoy. You can say, that proper process enables more productivity, but I haven't experienced that, and building better process isn't something I'm good at, so it makes sense for me to seek out opportunities with less process and more individual ownership and deployment freedom so I can be a cowboy.
i agree with this a lot about pioneers not “leveling up.” saying you’re a pioneer and can only do the initial work on a project and not bring it past the first stage isn’t some great skill. kind of like someone who gets promoted to level where they can’t perform and then are out of a job. and quitting the company because of it just shows immaturity and inability to learn
“pioneers” as mentioned in this article are not critical to a business, it’s the people who can do both ends of this spectrum
What makes me uncomfortable is tying my professional identity up with a part of the product lifecycle.
Sometimes it's just fun to take on risk, and other times, great to be able to eliminate risk. But fundamentally, almost everything in tech is a kind of wicked problem. Sometimes that problem domain sometimes shifts to areas where you have less control.
Where things usually go off the rails are when you feel like you're no longer making contributions. I find _this_ is really what "pioneer people" are really griping about. It isn't that they need to "move fast and break things" or other such BS. It's that they got used to having control and seeing the impact of their work. After a while, things become complicated, and it becomes hard to see how they make much of a difference.
Usually when I see one smart, inspired person leave because of "process", there's often a team left behind frequently spinning their wheels on something useless.
Well, I am again gradually becoming a pioneer -- after having been a very solid repair/maintenance programmer for most of my career. So the distinction in the article feels artificial and kind of extreme to me. It did a good job illustrating two extremes though, so not complaining.
Reason for my transition back to pioneer is: teammates aren't willing to listen to me and I can literally observe how they paint themselves into a corner, in real time, with front-row seat. And if I even dare imply something like "I told you so" when things inevitably come to fixing tech debt for weeks without meaningful new features deployed then I get branded as non-constructive and bad team player, with them completely skipping the part where I offered help with their concrete ticket (and a small refactoring as I go).
And that's only one example out of hundreds -- obviously I'm not talking about only one workplace.
It got so bad that I started using 1-2h work hours a day to work on my own stuff, or just do invisible huge coding reviews and put notes aside with the hope they'll be useful one day. That way I can't get criticised for being the only guy who doesn't idolise shipping above everything else. I do ship but not several times a day, and I try to touch code carefully.
I do agree shipping should be in the top priorities but it should be balanced with expected future tech debt and the ability to revisit the code months later and be actually able to work on it again. And of course, that never happens. Shipping is always an absolute top priority with zero "if"-s or "but"-s. Sigh.
/rant
---
Back to the article's topic, well, I was just saying that I am one of these people who were pioneers as teens and during their early career, quickly became the trusted go-to repair guy for everyone around because that made money and helped many others, but are now drifting back to being a tinkerer and a pioneer because nobody seems to want to listen to experience.
I strongly like the idea of pioneers as compared to "settlers" and "town planners" (see Simon Wardley's writing). But the idea that pioneers have and/or benefit from no process is BS.
The best pioneer is structured and has process. A pioneer's job is to efficiently conduct tests to derisk some space. This involves the creation of lots of artifacts which do not, usually and probably for the best, include running, trustworthy foundational code.
But that doesn't mean that work wasn't full of process. It's just often a little harder to scale and comes intuitively to some individuals. The process includes things like (a) rapidly reintegrating learning, (b) listing out assumptions and attacking them with an invalidation-minded perspective, (c) brainstorming novel ways to uncover new information cheaply, and (d) rapidly building new mental models and sharing them.
That's process, too, but not process that creates a functioning machine. Just one that proves such a machine could exist.
It's critical to not run the wrong process at the wrong time, so leaving when the pioneering is over can be a good move, but so might finding a new place for pioneering on the edges of the "settling" that's begun to move in.
The problem is that in mature companies there is often no next version where you need pioneers. The next version is just an incremental change to the previous version. If the business is very management or sales driven then as engineer you are told exactly what to do in the shortest time. No room for or interest in pioneering work.
Corollary to this is when a business is so mature that they decide to no longer take risks (or higher risk) by designing a new product, or go after a new market or go for the next disruptive change that is valid. Instead they go after reliability based on exploiting a current product or resource or asset and optimize the product or process to extract out yet even more value. The latter is always viewed as safer and more predictable than the former. The truth is to recognize that that is what is happening and accepting that in the long run, the latter will not produce sustainable growth.
Even worse, sometimes it turns out that the business assumptions baked into the first version were completely wrong, and now have to be undone. The original pioneers can be the worst suited people for that work, if they are emotionally invested in the old approach.
I disagree - a bit. There is often a blue ocean that can be created in the industry or around it, and usually pioneers are part of a small group to see it first.
That’s true! But the clusterfuck is a necessary part of the product birthing process, not something to be scorned. The baby product now needs to be nurtured and educated into a functioning adult. There are plenty of opportunities here. And this is where branding yourself comes in, to get the political power you need to do something right and fun with the product. Instead of a maintenance programmer, call yourself a “scalability engineer.” If you’re in a regulatory heavy business, read the regulatory manuals and become a “compliance engineer.” It will be super helpful for your career and give you the clout you need to make the necessary product improvements as the business matures. Just my two cents. I think you’re being downvoted because your tone comes across as scornful, but it’s really a fantastic opportunity for back end devs to make a difference.
I don't think the clusterf*ck is necessary for anything. It is an indication of immature people working on something when a product goes through a phase like that. Of course, at the stage where the project is 100 lines large one does not need much structure but it can be added gradually without a noticable disruption in the flow of features supported.
The whole 'scalability engineer' and 'compliance engineer' title mumbo jumbo sounds very phoney to me. As far as the compliance part is concerned I feel inclined to make up some fake dictionary definition for it in the style of the devils dictionary for maximum cynicism. Compliance: a lot of paperwork that asserts that a set of desirable attributes apply to the mirage that management has dreamt up about a project. The mirage may or may not be in any way related to the actual state of said project.
Your cynicism about compliance is misplaced IMO. Compliance is about making sure the product covers things that are boring but important, like security, privacy, and accessibility. These are things that the pioneers blithely ignore so they can ship something. But if they continue to be ignored, there are real, sometimes disastrous, consequences (even if the disaster is just for one person, e.g. an otherwise well-qualified blind person losing their job because an app they're required to use is inaccessible).
That’s a fair and reasonable perspective. I’m curious if you’ve worked on such a product that had a baked-in level of maturity from the start? I never have. I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck!
Scalability engineer and compliance engineer very much are phony mumbo jumbo from the perspective of a software engineer. However from the business perspective they are very real and I think they are helpful to communicate one’s own level of maturity and ability for the business owners to trust you to get things done for them. It’s about communication and signaling more than the reality of what you do.
I have seen the startup stages of software projects with varying levels of quality. The whole spectrum from very bad to very good can be observed and/or participated in in the wild. The good ones start out with one experienced developer. After two or three features have been added (within two weeks to a month) more developers, possibly less experienced ones can be added. Their number should grow somewhat slowly mainly to make sure that they are not getting in each others way too much. Practices that make this work are automated testing and code review. Occasionally, some pair programming can be practiced, especially when some refactoring is needed. I am talking about limited refactoring here, maybe taking two to three days. If the project can be split in a front end and a back end one may start out with two developers. In theory a system that consists of N services might start with N developers but if N starts out larger than 3 one is quite likely engaging in over engineering.
I agree with cjfd; it's a false dichotomy. "Either we put zero effort into making this code maintainable, or we won't move fast enough."
> I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck!
I'm personally working on a v1, and (you'll have to take my word for it) it is far from that.
We are making conscious decisions: "here's a guess about the future that we're confident about, so we're willing to add in more structure/abstraction here," or, "We're not sure about the future of this feature set; let's be clean but minimal about it."
Also, co-workers have raved about our work on this project, including speed. So that's further evidence that it's a false dichotomy.
At least you have something. I had to come to respect this.
The code may have been bad, thrown together, and not architected correctly, but, if the company was able to get customers and become profitable enough or get funding to hire people to clean it up, they were a success.
The Twitter codebase was a well known clusterfuck, but they got product market fit and were able to survive long enough and become capitalized well enough to rearchitect their system.
This is key, regardless of whether you think that "doing it right the first time" would have not taken meaningfully longer, and paid off in the long run over and over.
For any meaningful product, you want to get customer feedback early and often, and you want to do it before your competitors get a chance to.
I say this as a more stereotypically "Process" person/developer than a "Pioneer". I know too many failure scenarios. I overthink. I get into analysis paralysis when there is an open page. I need that Pioneer to help my company and my team get started.
But give me an existing system, and I'll mold it and expand it as quickly as that 10x Pioneer.
I love taking shipped hacked together code, and gradually refactoring it and improving it for 10x, 100x scalability of both system throughput and development team growth.
The important factor here is shipped. In production, with customers. Customers who already see the value and benefit, and don't mind the occasional blips and glitches that will take much longer to fix (and probably require massive rewrites) to fix behind the scenes.
Beautiful code without users is worse than nothing at all.
I like to think of it as - pioneers build the base enough to prove some part of product, market, or technology so there is later revenue for the engineers to have a job. I've heard tons of engineers teams whine about technical debt - without realizing that there would be no company to employ them.
Pioneers tend to be good at many domains; engineers tend to be great at one or a subset of domains. Specialists refine the toolsets and methodologies, while pioneers main goal is to just help prove business value.
What about in the case where it's already known that there is a product-market fit?
When Pioneers leave an absolute mess in their wake, changes to the project take more and
more time. There is a trade-off, and the "immature pioneer" mindset (working with no thought for the future maintenance of the code) can make the scaling / maturing process of a product needlessly painful and slow.
Maintenance is not a “problem” even if I am the maintainer or in my case, the “rearchiterer”. It’s what they are paying me to do. What a company needs at one phase of its existence is different than at another phase.
It would be just as wrong for me to come into a company at the beginning of its existence when they are just trying to go from 0 to MVP and worry about unit tests, branching strategy, and “process” as it would be to promote the pioneer to a team lead.
Interesting analogy, and I would agree if the developer is intentionally concealing their actions to escape consequences.
However, the situation is more often someone inexperienced doing a bad job, or someone experienced doing a bad job because they're crushed by unrealistic deadlines, or someone cutting corners intentionally because the company is in a do-or-die situation. None of these are immoral, but result in the same outcome.
Very interesting piece. Same experience here (jump in, build knowledge assets, build team). Last part different, be CTO's worst fear, have you team scrambled, projects refused, go somewhere else taking on a bigger and harder challenge. Funny part is they lost 2 years, hired obedient lead, then went on building exactly what I presented them. They even went to the press claiming this stuff was their own idea. How would you feel ?
Yes, we hate meetings. We understand each other fast, work together at stellar speed, clash often. Sometimes, we code without tests. Bad practice ? Break my code.
Pionners and process people are at odds most of the time. Let's push this idea further.
Pionners are always despised by the tenants of current state of affairs. Bourdieu explained this very well regarding art. Why ? Process people have the power and spent most of their lives perfecting their current knowledge and craft. Inventing something disruptive will disrupt their power. Galileo, one example amongst a lot.
Even the most advanced people at their time have had theirs quirks around this fact. Maxwell predicted that his models had solved physics and that the few problems remaining (like Black-body radiation) were minor problems, where it led to relativity and a new revolution in physics.
Process people are made of habits that work well, ensuring intellectual comfort and easiness, which is very reassuring. We make you itch and scratch, because we live in never-ending uncertainty and know that theories are ephemeral in the grand scheme of things.
Some dogmas of biology have collapsed in recent time. One of the most funny was "brain cells don't divide after end of adult growth"...
This line of reasoning also invalidates a whole part of human theories about things. Fukuoka explained it very clearly: we draw pseudo-conclusions, only valid in a closed-system which in itself is a pale representation of reality. We try to reduce complexity to make it manageable by our current brain power. Those conclusions are wrong, when complexity is taken into account. Economics is based on wrong assumptions, but it works most of the time.
Knowing this leads to respect and not mess with fundamental building blocks we don't understand (gene editing is such a monstruosity).
Tell me about discomfort.
Pionners are risk-taking, and don't bother about controversies, they create those. They are despised and critisized by process people because they disrupt and destroy, as they create new paradigms. Destruction créatrice. They overthrow intellectual kings.
Speaking of experience, being a pionner is very difficult as everyone is against you and you got to prove to everyone that what you're doing is better and possible.
Let's digress about personal examples in order to settle those assumptions into reality.
When I was a kid I could solve the problems that math teacher gave using different methods. Most teachers would not even look at the method but rather blame it. They didn't want to make the intellectual effort to understand the stuff.
When I did my PhD I destroyed theories of some peers using experiments. Well, let me tell you, my academic career didn't last long.
When I worked in aerospace, during the day my boss yelled at me "shitty stuff", while copying my code in another codebase at night.
How can pionners bring value to this world ? It's as hard as producing metallic hydrogen. How to convince an investor when you always look at things from another POV. When the problem you're tackling is far from solved. Risk seems too high.
Let's rather focus on solving big corp problems and get easy money.
Funny thing is : we have an ability to connect to each other. A gang of weirdos trying to attack the doxa.
So, the problem is : can there be a collaboration between those two kind of people ? Here is a very fun example. Rust. This language brings to a large audience some very powerful concepts like ownership, truly a pioneering work. What do people do with that language ? Rewrite the same tools.
Problem with pionners is we cannot stand repetitive work. So after the thrill of finding a new solution is gone, we tackle some other problem. That's were we can build together as innovating is far from enough, and there is a lot of work left for process people, as told by aforementioned piece.
That's why I only work in small startups. Because once the group is too large, we are naturally surrounded by process people. Pionners are a small fraction of people. Once critical mass is reached, burden to leap forward is simply too high.
Don't get me wrong. Too many pioneers together is a bad mix too. Pionners have strong opinions and this may lead to frequent clash and incompatibilities. Process people all have the same processes, so there is less to argue about.
Following that line of reasoning, large organisations are just unable to produce breakthroughs. When processes take over, you're doomed.
So much respect for Elon Musk who has built crazy ventures that manages to break paradigms. That's a crazy achievement. Same holds for Steve Jobs, who could torture an org to squeeze new ideas.
But what's important ? Intellectual thrill or steady business ? Choose your horse !
Pure pioneers look like the fabled "10x programmer" on the outside, but leave a hellscape of technical debt in their wake.
Pure process people are so busy building their perfect ivory tower they miss the actual goal of getting stuff done.
Somewhere in the middle, where you've figured out how to move fast but also avoid causing the tech debt you've encountered in the past is the right place to be.
This usually boils down to having good boilerplate when you start something - for code, that might be a trivial but well understood linting and testing framework that you can add at the start of a project, or a simple way to start documenting a business process.