Ask HN: Is it sloppy coding culture or just me/ADHD?
I feel super unproductive at work. Looking back at my career I've hit peak productivity when I could manage a codebase, the culture around the codebase, and external visibility. But the culture of my current group is: heroic hacking. Other team members seem able to work in this environment but I feel paralyzed in this atmosphere of slapdash jupyter notebooks, untested undocumented sprawling ML models, and not an interface in sight. 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.
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?
57 comments
[ 3.0 ms ] story [ 116 ms ] threadThe 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?'"
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
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.
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.
Yes, I'm cynical.
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.
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
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.
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.
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.
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.
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?"
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?
Yes, I think this could be the crux: maintenance oriented vs prototype oriented practices
Badly designed architecture, or one designed too early, can be tech debt as well.
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.
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.
https://www.joelonsoftware.com/2001/12/25/getting-things-don...
“Getting Things Done When You’re Only a Grunt”
- 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.
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.
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?
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.
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.
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.
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.
* 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.
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)
(… love the D&D analogy. But very much agree with its meaning too!)
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.