One view is: this is just n00b startup engineering.
Another view: maybe my old engineering practices are a crutch? Have I relied on thoughtful design, thorough tests, version control policies, documentation, static analysis... because I have untreated ADHD or sth and can only focus on one modular chunk of code at a time? Is adderall eating engineering practices? How do these other engineers get anything done?
Do I need pills or a new position?
* 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.
Yes, I'm cynical.
- 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.
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.
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.
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
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?
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.
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.
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.
https://www.joelonsoftware.com/2001/12/25/getting-things-don...
“Getting Things Done When You’re Only a Grunt”
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.
The remark of the elephant in Her Majesty's Servants (https://www.kiplingsociety.co.uk/tale/her-majestys-servants....) is spot-on here: "I can see inside my head what will happen when a shell bursts; and you bullocks can’t."
The bullocks of course reply thus: "'But it [the blood] is not here,' said the camel and the bullocks. 'Why are you so stupid?'"
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
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.