There's aspects of personality I think. Let's use D&D terminology to make two caricatures.

* Wizards need to prepare their spells before they can be cast. They want upfront planning and design. They rely on rules and systematization. They prefer top-down design, breaking a large problem into smaller and simpler ones.

* Sorcerers cast spells at will. They're more volatile, but their flexibility is greater. They prefer to inundate themselves in the problem and experiment their way forward and to sort of mold the code like clay until it does what it should. They prefer bottom-up design, starting by constructing small pieces and moving on to growing a large solution organically.

Wizard programmers will think sorcerers are sloppy, undisciplined and out of control.

Sorcerer programmers will think wizards are overbearing bureaucrats stifling progress with unnecessary rules and plans.

I don't think there's a clear cut best approach here. I've known developers who were extremely productive in the long term with both approaches. It is probably fairly domain dependent. Wizardry is significantly more reliable when the domain is well understood, sorcery has a definite upper hand in a poorly understood domain.

I think the strongest programmer is capable of both styles. They're very different disciplines though, so this is hard. Wizardry requires capacity for patience and discipline, while sorcery requires a strong intuition for design and faith that the design will come together despite not knowing how in the moment.

Those strongest programmers you mention are clearly multiclassing minmax D&D players :D

(… love the D&D analogy. But very much agree with its meaning too!)

To be fair the strongest programmers are probably just gifted, outliers not just in reason and intuition but also people skills.

I love this idea, I think it’s going to make Monday easier. I wonder how much this is two types of people and how much it’s two ways of working that different people got used to.

My hunch is that when you started programming matters.

I'm more of a sorcerer, and I first started coding when I was like 6-7 and never stopped. A seven year old really doesn't have much capacity for upfront design, planning or reasoning, so I learned to design code intuitively. I feel a lot of people who didn't really get into coding until their late teens, university maybe, they tend to lean more toward using reason than intuition.

This is mostly relying on low-N observations though so no idea if it's true. Seems plausible at least.

(although as a counterpoint I'll admit I'm a bit of a cut first and measure later sort of person even outside of programming)

For what it’s worth I don’t think your age thing is accurate. As a counterpoint I started as a teen and still prefer to grow the code mostly organically and trust that a) I can make fairly robust decisions on the fly for durable decisions and the non durable ones don’t need as much thought. Even up front planning will miss design mistakes when review by multiple people.

It might be more relevant how you started programming. If you're playing with things, taking them apart, making them do odd things — it's likely you pick up a bottom-up understanding, messing with minor aspects at first. That lends itself to becoming a "sorcerer". Conversely, if you acquire a skill in pursuit of solving a specific problem (and matching how things are taught, mostly), you start top-down, becoming a "wizard".

Yeah that sounds like a more plausible hypothesis. Although the line is very blurred about how you defined “specific problem”. Everything I started programming with was specific problem I was having at the time (writing a media indexer to dedupe my music library, writing a presence simulator to fool those early “pay you for browsing your computer” adware) rather than just playing around for the sake of playing around. From one respective I was picking problems randomly and seeing if I could solve them so I guess that’s more playing around. But it’s not like playing around with graphics where you try to see what kind of effects you can create.

IMO it's partly a problem between sales and the "sprint" based development. Everyone wants fast, new and shiny and a 2 week sprint. No one wants to do tests, maintenance or even any architectural planning for their software beyond a single sprint, and architectural decisions don't flow between sprints. That's what happens when entire companies cargo-cult adopt scrum for their "agile" process, and the software suffers from the engineering equivalent of quarterly report syndrome (nothing longer than a quarter is really planned out in many publicly held companies because shareholder earnings reports are the highest priority.)

Yes, I'm cynical.

I think it's this, but this is just one symptom of the real problem, which is too many so-called "non-tech" people in the tech industry. There's no way a person who isn't a really good programmer (or something close to it) can effectively make decisions on a day-to-day basis. That's why managers have to guess or defer to a tech lead when it comes to real technical decisions/conversations (hence the tech lead who lives in meetings with the client).

To use a metaphor, imagine if a project manager at a car company boasted about "not being a car person", or couldn't explain how the main parts (like the engine) worked. Yet, this is pretty much the norm in many areas of the industry; tech is a cash cow, so it's attracted people with a desire for money where their knowledge and experience should be. You can't really fake it being a programmer, so they've only been able to infiltrate managerial positions.

(And to be clear, the way the tech industry supports people learning is fucking tops. I'm not talking about those people, I'm talking about people (mostly managers) who are not concerned about their basic lack of knowledge)

Yes, I'm also cynical.

Another perspective... software in particular skews the usual production economics because of its low per unit cost vs the extremely high scalability and thus need for marketing and other business support.

A furniture business with ten people producing the furniture would probably max out their production with just a tiny bit of non carpenter support.

A software business with ten devs, on the other hand, could grow from tens to millions of users with the right non tech support, whether it's marketing or seeking VC funding, even if the underlying product only barely kept growing.

Most of these processes are there for business needs, not dev needs, with the company trying to maximize the value of their super expensive devs.

It's the assembly line model of software dev, where some higher up decides what to build and chunks it into individual production stations that each just produces their part with minimal fuss. In this world, managers don't need technical skills as much as waterfall skills. The spirit of it is completely different. It's not meant to enhance developer creativity but restrain it so that it's focused on a predefined chunk of business need.

Is this really true at car companies? I don't know, legitimately curious

My sense at least is that at some point every company becomes "interchangeable people with business degrees and MBAs"

I agree that line is fairly low in tech, but curious about other industries

Absolutely agreed. I'm on a team that is presently working on some rewrites of major components in our app from an older frontend framework to React with TS. It takes a while to get to even parity, it's tedious, and tricky to get right, and 3 of us are independently working on separate major bits concurrently. We also have other stuff, code reviews, meetings, Jira, other bugs to fix, and the 2 week sprint just makes it feel like I'm constantly on edge, because it's not going to be anywhere useful in 1 sprint or likely 2, and it doesn't offer any breathing room. Having more two week blocks rather less longer blocks of time also introduces more of the overhead that accompanies agile crap, and reduces time to get the stuff done even further. If we know it'll probably take 4-6 weeks to do something to the standard we want it, we should probably at least be doing 3 week cycles, or dynamically change it depending on our goals, but that never happens.

2 week sprints optimize for fast, poorer quality work, and much less of it, because for a healthy practice one needs margin. Margin to accept other pointless meetings, margin to deliver hotfixes, margin to do work carefully without burning out.

Yes, I'm cynical.

You're not the only one. I too am also doing somewhat of a similar migration with similar staffing and not enough time, and the project managers and product owners are more concerned ed about the dates they committed to than what us devs need to make it all possible. The last site works, but it has dragons and monsters under the hood.these things take time, but because us devs are not able to clearly estimate.the end of the line, we stick with the too tight time frames...

Exercise saying “No” as much as you can. The less you say it the more it becomes a like a right stripped away.

Yeah we have 2 week springs inside ~quarter long projects. But I find the projects come and go and I'm still providing weekly user support for projects that "ended" quarters ago. Like there's no company dialect word for "platform".

Mirrors my experience somewhat. Often these places are feature factories that heavily advertise their scrum/agile practices without actually thinking about if they apply or fit (or are even implemented correctly).

What often follows is a thick layer of success theatre with each feature release.

Rinse repeat.

Any voices trying to point the flaws, inefficiencies or low hanging fruits for doing things better are drowned out or made to feel the odd one out.

I know, as I have been one of those voices.

Rich Hickey on sprints (30 second video): https://youtu.be/zPT-DuG0UjU

Ok, so if you’re the only one thinking it’s a problem, and assuming they’re not simultaneously and uniquely non-rational, there may be some logic to this. Questions:

- is the code / models / software expected to last a long time? Are these prototypes by another name?

— will you actually have to pay for that tech debt one day? Are you paying for it now? Or Are there strong business winds that might require a total change or shift regardless of code quality?

- are the products / hacks / software components strongly coupled? Are there strong dependencies between each team members output, causing you to be blocked on un hacking the hacks?

- how much technical communication is expected to be person to person, ad hoc? is there an expectation that when you need to use or work with someone’s component, you should promptly sync with them?

I say this as someone who 1) loves code quality 2) has worked in testing tools dev 3) has also worked on early stage teams.

And sometimes, when you’re early stage, the highest value you can deliver is understanding what you’re actually trying to build. Hence, lots of Prototypes, experiments, measured hacks, differing conventions, etc.

Now, all my prototyping days I’d say code quality was high (devs cared). But while tests and docs were super impressive, often they weren’t that impactful.

Find a new position, it's not just you.

I get a huge amount of satisfaction having a large collection of tests exploring every uses case and edge case of my services public api and the safety with which it means I can embark on ambitious refactors.

Yeah, my first reaction was that it's not you, it's the team/culture fit. Get out.

I have colleagues who move fast, break things, and don’t believe in interfaces. They are highly productive and it’s hard to cooperate with them in any other setting than pair programming, which does work great.

Then I have colleagues who write the interface first, tests second, and finally write code.

Cooperation between these cultures is hard. It works best to have cycles between areas of a code base. The interfacers can easily end up as janitors and cleaners, and there can be friction.

I think both styles are warranted, especially in startups.

I like working with the "move fast and break things" people if they take my feedback into account when it comes time for the "cleaning" or PR review, AND if they have the time to properly address the feedback vs just being pressured to ship immediately.

Thanks, this is a very balanced answer.

It reminds me of the testing versus debugging: some folks are great at testing code so it never breaks, others are better at churning out code and debugging it as they go.

Yes ! As Harryhirsch said, change of position !

DO DEV OPS

You will most probably not be able to change the culture of a company on your own. So you could just leave before they realize the code is unmaintainable. (plot twist : you often realize this in some hard way)

if you have these engineering skills, I suggest you do DevOps ! designs, modeling, docs, manage a codebase, Tests, version control, policies, static analysis... perfectly match what they have to do

Keep the mindset, learn some gitlab pipelines, and you'll be a rock star for employers

Too much focus on software quality and zealous DevOps before product market fit can kill startups too (I even experienced it). Nobody cares about a useless product with good quality. Nothing wrong with that, as others have said maybe change for a larger company and a more mature product.

I am about a month into devops / platform role and enjoying it alot for these reasons. Of course ymmv but the job of making other developers lives easier is quite nice. But it is not really about application code architecture, maybe that should be a team/thing too.

yes, devops teams are chill as well

Their actual tech work is made by code. And it leaves them time to chat with anyone else at the company, or at the customer, to figure out new things that could serve them.

I also love to just teach someone about the tools. When the needs can be served super easily and the guy is interested, it's great not to do the work yourself, but to guide them into this culture of 'automation&chats over teas'.

The more ppl do pipeline on their own, aim for value and clean, simple code, go for high added value work, and drink tea with coworkers and customers, the more your company starts to gain.

You probably need a new position. Not every position is right for every person. If the team or product is in its nascent stages, it's a total waste to spend time of software quality. That's just how it is in small-stage software ventures. Go work somewhere bigger.

It’s not old vs new. It seems you switched from building big established systems into a smaller, prototyping-driven project.

There are two classic books on the subject from 1990s: „Extreme programming”, and „Pragmatic programmer”. Both touch upon the subject of premature optimisation and about finding the proper timing for refactoring.

In essence - you build architecture when you know exactly what you’re building and you refactor when there is a need to do so.

Also, you say that you switched from a project with a bigger codebase and solid processes. In your previous projects, did you work on systems at the same stage of development?

Yea. There are some people who love to sit there and think everything out and draw on whiteboards during meetings for hours, have multiple test envs, have QA run over everthing, make sure their commit messages are all the same format and have lots of information, roll out a feature slowly to find bugs before it hits everyone.

Then there are people who want to get a feature done so they can see if it has any value. They would rather build something and then redo it later if it turns out it's not correct. They never read the commit messages so don't care about how they're formatted.

One is make sure everything you do is really good and the other is move quickly and break things. One side is "We don't need to rush bug fixes because we never release anything majorly broken" and the other side is "It's faster to rush a quick bug fix than it is to spend 6 weeks rolling out a feature." Both have their pros and cons. And depending where the company you're working for is in their lifecycle depends on what sort of development team they should have. Facbook for example should be spending large amount of time ensuring things work properly. While the 6-month startup with 18 months runway should be moving as quickly as possible to figure out what works and what doesn't.

Some people prefer one method over the other. Some like the middle ground between the two. Everyone is different. If a developer is one a team and doesn't like where the team is and how they act is normally better to just get another job. Very rarely is a company going to get rid of an entire dev team which is what would be required to change the culture quickly. And from experience, there isn't much worse team wise than having someone go on and on about commit message standards, code style, etc when half the system is basically on fire.

Strong n00b vibes from your description. Software is a craft, and they sound like amateur craftsmen. Dont take it personally, they just dont know any better

New position.

My workplace is different - we've been in an under-resourced, over-committed state for about 3 years and we KNOW we need more established standards, better testing, and a handle on our tech debt. We just don't have it yet, so instead of blank stares and "what are you talking about", it's exasperated sighs and "yep, we gotta work on that". But our whole team is on the same page and committed to the idea, so that's definitely a plus.

Does it work for them?

Paul Graham talked about logging into the production server and changing live code while on the phone with a customer. In some organizations this would be horrifying of not downright illegal, but Graham mention this as an example of succesful fast-moving startup culture.

There is no absolute “best practices” without context.

The coding culture migt be fine for that particular organization, but it migt be a bad fit for your temprament.

> When I suggest we find consensus on an architecture or coding practices or even commit conventions

My suggestion to you is to give up on this step, and just do whatever you think is a good idea yourself.

If it turns out that your coding practices, architectural decisions, etc are useful and productive, then others will follow suit.

Just skip the big discussion, everyone having their two cents, consensus idea.

Sometimes things are messy in the early days. Are things getting out of control at this particular company? Hard to say. If you want to push for change be polite and persistent and focus on one or two key changes to the workflow. Not everything at once. Or if you can’t stand working this way you could jump to a more mature startup.

> can’t stand working this way

Yes what drives me crazy is not that we're racking up tech debt (which is appropriate in some contexts), but rather that it seems I'm the only one with that healthy sense of guilt/shame, that foresight that our shortcuts now will pay off in headaches later. There's this unblinking straightfaced attitude of "why would we do it any other way?"

Is it possible they've never seen it the other way?

I'm imagining someone who leaves messy school projects to join a chaotic startup to join a chaotic startup...

Do people on the team have experience maintaining things long term or working with legacy systems?

> experience maintaining

Yes, I think this could be the crux: maintenance oriented vs prototype oriented practices

Is it tech debt or a lack of architecture?

Badly designed architecture, or one designed too early, can be tech debt as well.

Kinda my feeling when looking at python shops and dynamic languages: code that never exits the prototype stage.

That code that doesn’t exit the prototype stage lives in production by the way.

Classic on the subject:

https://www.joelonsoftware.com/2001/12/25/getting-things-don...

“Getting Things Done When You’re Only a Grunt”

That must have been before I started reading Joel. I had to discover most of that list the hard way. The best way I’ve found to create pockets of excellence is to start from the build system (or once from version control) and build up and out from there. You need lines in the sand, where on one side of the line nothing stupid is happening. You can sometimes build that down at the bottom of a call tree, but if you can delay the moment in the code where the first really stupid thing happens, you can give yourself a toehold you can build out from, like branches of a tree. You also start to have some of the knowledge necessary to become a lead, because you begin to see how the pieces fit together and everyone sees your hand in the commit history, instead of buried in leaf functions nobody looks at.

Sounds like the team sucks, run.

Didn't sound like there's a team. More that everyone is working in their own silo. Under those conditions do your own thing.

Similar state of affairs in my current "team". None of us really work on the same thing at the same time.

I'm currently fascinated by the comparison of me and a colleague. They bang out code (comparatively) but it's clear from the waves of fixes and bugs they also have to fix that the net result is not really moving faster overall than I do. With my more investigation, more design and incremental expansion.

They originated in quick to market software where as I began in high reliability and safety critical stuff. Personally I hate modern software that is tossed out fast, barely functional and always in need of updates. But in our hyper consumption economics there's not much scope for doing things properly.

go into ops!

this will also be job security. you can work until 100 if you want to. (you won't want to. but you'll be good enough to charge accordingly.)

this is a circus and you are not in fact a clown. Move accordingly.

I’m wondering if the answer isn’t to do consulting. Build up your private toolkit of frameworks and best practices so you can get super fast at providing high quality results.

Yes thanks, consulting does sound like the way to provide the most value

> When I suggest we find consensus on an architecture or coding practices or even commit conventions, I get blank faces that seem to ask "what are you talking about". I feel gaslighted about tech debt.

Depends on the size of the company, if you're frantically finding product-market fit, then this is fine. However, if you have an established product, then you might be correct in explaining the benefits of solidifying an architecture and best-practices...

TLDR: YOLO dev until the product resonates with customers

I don't think size of company is as relevant as the market sector. My employer is a 40-50k work force globally and it's bash stuff out. But similar size companies doing medical or CNC, etc, where errors kill write to best practice.

This is just how the industry seems to be now. It’s gotten really bad over the last five years. If it isn’t broken, people aren’t touching code, and there aren’t enough people to do the work anyhow.

I don't think casually diagnosing ADHD/ADD is helpful, but your desire for structure is not ADHD/ADD.

If anything, the people who bounce from task to task and making it up as they go are leaning that way. Pills won't help you add chaos, and you shouldn't want that.

I don’t think the desire for structure is not ADHD. Structure helps everyone lower cognitive load

There’s an in between very much possible and necessary here. But yea in your case it sounds like startup noobs.