
Ask HN: Are my expectations on code quality and professionalism too high? - veggiepulse
I have lost perspective on what is reasonable to expect, and need a reality check from HN.<p>Some time ago, I left a large-ish company with what I perceived as overall quite good engineering to join a smaller company. When I say &quot;quite good&quot;, I don&#x27;t mean perfect, but what I consider the basics were there<p>- Code review, where we would consider architectural concerns, failure cases, etc. ensuring maintainability. Shortcuts were taken intentionally with a plan to address them<p>- Test coverage was good enough that you could generally rely on the CI to release to production<p>- Normal development workflow would be to have tests running while developing, adding tests as you introduce functionality. For some projects that didn&#x27;t have adequate test coverage, developing might involve running the service locally and connecting to staging instances of dependencies<p>- Deployments were automated and infrastructure was managed in code<p>Those are what I consider the basics. Other things I don&#x27;t expect from every company and am fine setting up myself as needed.<p>In $current_company, I was surprised that none of the basics were there. All agree to do these things, but with the slightest bit of pressure those principles are gone and people go back to pushing directly to prod, connecting to prod DBs during development, breaking tests, writing spaghetti code with no review, leaving us worse off than we were before. This is frustrating since I see how slow dev is, and I know how fast it is to develop when people write good code with discipline. Most devs in the company don&#x27;t have experience with other kind of environments (even &quot;senior&quot; ones), I think they just can&#x27;t imagine another way. My disappointment isn&#x27;t with the current state, but that people of all levels are making it worse instead of better.<p>These setbacks are demoralizing, but I&#x27;m wondering if my standards are unreasonable. That this is what mid-sized companies are and I just have to endure and keep pushing
======
ransom1538
Me as a manager at a startup: "Look, we have 5 months of runway. Does that
make sense?"

Young dev from large corp: "Yes. But if you don't use Terraform we wont be
able to see our infrastructure changes over time. We don't even have a proper
code review process."

Me as a manager at a startup: "We have two micro instances. Do not install
Terraform. Finish the import prototype... now."

Young dev from large corp: "Sigh, ok, just saying in 2 years from now we wont
be in a good spot". [Then proceeds to blow 2 hours complaining on hacker
news.]

~~~
an_d_rew
> Young dev from large corp: "Sigh, ok, just saying in 2 years from now we
> wont be in a good spot".

Except in my experience it’s not two _years_ , it’s two _months_. And I can
set up two micro instances with terraform in less than an hour.

So soon you’re burning your three months of runway with development at 20-50%
efficiency, and have no ability to pivot, if needed, because your
infrastructure is rigid and hardcoded.

Neither scenario is “correct”, there is only “judgement”, and it can be
devastatingly incorrect either way.

A lot of people with strong or extreme opinions (too little or too much tech
debt) are inadvertently being fooled by “personal survivor bias“.

~~~
PragmaticPulp
> And I can set up two micro instances with terraform in less than an hour.

The post was more of a metaphor than a concrete example.

However, as a manager I can’t count how many times my team has declared that
they can do something in under a day only to have it become a part-time job
for someone to maintain indefinitely, or a multi-week rabbit hole as they
debug some unexpected behavior, or technical debt as they neglect to document
their solution, or a productivity bottleneck as everyone else must now either
learn Terraform or wait for the Terraform guy to be available to help and so
on.

When I transitioned from IC engineer to engineering manager, I quickly learned
that engineers frequently assume the best-case scenario for their time
estimates, while managers end up planning for the worst-case scenario. The
catch is that it’s difficult to tell an engineer that their time estimate
could be an order of magnitude or more short of a realistic estimate without
implicitly insulting their abilities in the process. ICs also quickly forget
that many of us managers were once over-optimistic IC engineers as well.

~~~
eitally
When I was managing a large, distributed team of mostly mediocre engineers (at
a poor bigco), it was common to take the best case estimate (provided by a
senior engineer or architect), add 50-100% because due to lack of similarly
experienced engineers responsible for day-to-day coding, add 25-30% for SQA,
and add 50% for "business" delays (usually LOB heads who couldn't agree on
features, or who asked for utterly stupid things that we'd have to explain
away before we even got started ... like a web UI with a 52 column table meant
to emulate the previous Excel-based "system"). The result was frustration all
around because the senior engineers knew our estimates were crazy high
compared to what they'd be able to do independently, our business stakeholders
were mad because of the cost, and our CIO couldn't understand why it seemed
literally nothing was doable in less than several thousand person hours. Good
times.

But when you 1) don't have an constructive relationship between CIO/CTO and
business leaders, and 2) offshore everything not to follow-the-sun but purely
to save money (and then pay bottom of the barrel even in lower cost regions --
that company still only pays engineers 10-12 lakh in south India), you're
going to get an inefficient org creating crap quality software.

~~~
PragmaticPulp
It sounds like you had distributed decision making authority but concentrated
accountability for the outcome. Worst-case scenario.

> the senior engineers knew our estimates were crazy high compared to what
> they'd be able to do independently

Interestingly, I worked at a company where teams of engineers were given wide
latitude to design, implement, and deliver their features in isolation. The
theory was that engineers could be more productive if they were left alone to
make the decisions.

I'd say it worked about 1 in 4 times. The other 3 out of 4 times, engineers
created their own labyrinth of over-engineering, spent too much time building
things as reusable frameworks instead of simply getting the job done, and over
complicating the system with unnecessary "Wouldn't be cool if..." type
features.

~~~
tracker1
I find my sense of laziness keeps me from going too far down a rabbit hole
most of the time.

------
ajb
Your standards are reasonable. However, what's missing in a lot of comments is
a good process for assessing what the human and business factors that led to
where the company is now, and how to approach changing it. This is natural as
most people here are techies first, but it could lead to setting you up for a
bad experience.

There are very limited conditions, under which making this a blame exercise
would be the right answer.

There are also business conditions, under which this situation is _the best
that the business could have achieved by now_. Eg, if other things needed to
be higher priority for the viability of the business. Having said that, once
you are in such a situation it is difficult to get out of it, and hence such
situations tend to linger for much longer than any justification.

What you probably need to do now is find out how much appetite there is to
change, and what the blockers are.

~~~
arethuza
Strongly agree - particularly this part:

 _" what the human and business factors that led to where the company is now,
and how to approach changing it"_

This is a people problem, not a technology problem (or an opportunity if you
look at things that way).

------
zests
Near the start of my career I was at a small/medium sized company on a tiny
engineering team (3.5 people). We also had a lot of responsibility. Naturally
we did the only thing we could and formed silos and worked in our individual
silos without too much regard for testing or pull requests. We had a lot of
communication and I personally owned the "back-end" and was able to ship stuff
fast. I knew how every piece of code worked.

We eventually (to our protest) got a few new developers. They didn't fit in
our silo system. Our lack of tests/PRs didn't scale. We tried to reform and
encourage people to use pull requests but everyone requested review from one
developer who hardly looked at the code (scroll-scroll-scroll-lgtm reviewing.)
Code added from people outside of a silo didn't fit in at all with the rest of
the code base. Testing was never made a priority. Eventually I left and took
with me almost all of the institutional knowledge about some of our services.

We made horrible practices work until they didn't. No one would have been able
to join that team and fix it. The company I left for had mandatory testing,
multiple people code review and lots of discussion. It was like stepping in to
an entirely new world of software engineering. In my view you need to install
a good culture from the beginning or... good luck.

Its all about what you value as an engineer. You and I have similar values in
this regard and good practices are worth a lot to me. I don't think your ask
is unreasonable at all. I think you are just working with people with
different values.

~~~
JamesBarney
100% this.

For instance I'm an engineer who cares far more for business/technical
alignment than software practices.

If I had to choose between company A where I work closely with domain experts
but the software practices are awful, vs company B where we understand the
problem domain through 4 layers of management and business analysts but the
software practices are top notch. I'd choose company A every time.

Also poorly applied software practices upset me far more than no software
practices. For instance most places that implement code review don't use
structured code reviews and spend most of their time enforcing their tech
leads specific nitpicks (which are never written down) instead of actually
looking through the code to reduce bugs.

~~~
phailhaus
(Did you mean you'd choose company B?)

~~~
Radim
No, "company A" makes more sense from the context.

It's a matter of personal mental space: some SW engineers like to build things
that work and solve problems in the "outside world". For which you invariably
need deep domain knowledge. Technology is a tool, means to an end. "Company
A".

And others like to tinker with technology, big picture be damned: it's all
about isolated performance benchmarks, tech stack, purity. "Company B".

------
phyzome
Align it with business needs and observable outcomes.

Does the company suffer from outages? (Not just _have_ them—but actually
suffer from them.) When there's a production incident, do a root cause
analysis. If some of the root causes are related to coding and deployment
practices, make notes of that. Start aggregating that information. Soon you'll
have evidence that you can reduce outages by changing practices.

Does Product feel frustrated by development speed? Start taking surveys. How
much time is spent on fixing past mistakes/dealing with bad code/discovering
broken tests? That can be used as evidence too, when you want to start a
conversation with management about pausing in the race to tie your shoelaces.

~~~
hliyan
Agreed. I've found that part of the problem is how we (engineers) communicate
value to non-engineers. It's not right to get upset with a laymen/business
people without putting some effort into explaining. I've always found this
type of communication effective:

\- This database change will improve our page load time from 3s to 1s at the
cost of 25% of a sprint's capacity.

\- This library version change takes X amount of time because there are 45
sites in the code we need to change, and that impacts 120 test cases which we
need to rerun.

\- Not adopting this <security tech> puts us at risk of an incident like
<example incident from the news>.

~~~
karatestomp
I've noticed that (low- to mid-level, at least) business, marketing, and other
folks are generally a whole lot looser with their numbers than developers are.
That is, they'll toss around measures that aren't meaningful—and not just in
some quibbling sense of "well technically maybe these could possibly be wrong"
but truly are _very likely_ to be way off the mark—because they didn't
properly control for confounders or are clearly measuring the wrong thing or
whatever. They'll assign meaning to measures that could easily have nothing to
do with what they're saying they mean, or mean the opposite.

... but this usually goes over just fine. Rarely questioned. I think if they
_didn 't_ do this they'd be just as bad off as developers, if not worse due to
(again, generalizing) having a worse understanding of how to measure things
well.

------
rhizome31
This seems below average. No tests or code reviews is common but pushing
directly to prod or connecting to prod databases is unusual. It seems you've
gone from one extreme to the other. From what I've seen, even at companies
were people work in silos producing untested spaghetti code, production is
protected. In any case, among small companies, you'll have a hard time finding
the same level of quality you were used to. I'm not saying they don't exist
but I'd say it might be 10% of them.

~~~
sneak
This is how it struck me, as well. There is a big gradient, and this is the
extreme opposite end.

Just be thankful the devs can “push” to production and aren’t individually
rsyncing their code into the app servers. :)

------
ochronus
The standards you've described are totally reasonable! This sounds like an
amazing opportunity for you to have a really wide impact and a great chance
for the company to level up their game using your experience. I'm sure you've
thought about this already but it doesn't have to be a "fight" \- in many
cases what people need is some appealing reasons, e.g. describing how their
world would be much more amazing if they implemented X, Y and Z. Depending on
the size and stage of your company it might actually make sense to do it in a
'quick & dirty' way (e.g. dominating the market might be more important at an
early stage than doing it in a sustainable way) but even then they (tech
decision makers) should be aware of the tradeoffs and if they are, they should
be communicating the reasons to the whole company.

~~~
throwjuly2018
I recently joined a company(for less than ideal reasons) knowing they don't
follow basic software practices. I felt frustrated in initial months and then
took on challenge of evangelizing and implementing X.

But I'm getting too much resistance from "senior" developers who've been there
for 15-16 years. Everyone agreed to do X and circumvented it the very next
day.

This consumed so much of my time(outside office hours) and energy that now I
feel why do I bother making a change when I'm not getting paid or even
recognized for it.

------
poutrathor
The Joel Test :

[https://www.joelonsoftware.com/2000/08/09/the-joel-
test-12-s...](https://www.joelonsoftware.com/2000/08/09/the-joel-
test-12-steps-to-better-code/) *

The Joel Test

    
    
        Do you use source control?
        Can you make a build in one step?
        Do you make daily builds?
        Do you have a bug database?
        Do you fix bugs before writing new code?
        Do you have an up-to-date schedule?
        Do you have a spec?
        Do programmers have quiet working conditions?
        Do you use the best tools money can buy?
        Do you have testers?
        Do new candidates write code during their interview?
        Do you do hallway usability testing?

~~~
lojack
I think this is super helpful, I definitely don't think all scores on the Joel
test are equal. I would steer very clear of a company that had an 11 on the
Joel test because they didn't use source control, but would happily work at a
company with a score of 8 because they allowed some bugs, didn't have
dedicated testers, no hallway usability testing, and had to take a few steps
to build.

------
franee
Oh my. Run away.

If that is their current culture, there will be a lot of pushback if you want
to initiate changes. Especially among the senior (responsible for the mess)
ones who get defensive real fast.

Maybe ask more about how their engineering culture is next time around during
interviews.

~~~
toshk
Not in my experience.

The devs in teams I've worked with (including me) are most of time all quiete
aware of the places where their code en setup is lacking and as long as they
don't feel personally attacked are very happy with people who come with
implementable solutions.

The not feeling attacked and implementable parts are key.

~~~
luckylion
This. I've never had a negative response when I joined a project and
discovered obvious problems when I explained _why_ I think that they are or
are going to be a problem _and_ offered to help fix them. Nobody likes the guy
that shows up, says "that's all shit, you need to fix it", and vanishes again.
But I've never seen anyone hate the guy that shows up, says "I've noticed
there's a lot of friction around X. I think we could make it easier to work
with and more stable by doing Y".

And I've always liked it personally when somebody does that to me. When
somebody with a lot more experience and/or skill helps you, it's like some
super high level player carrying you through boss fights: you level up much
quicker than if you did it on your own.

~~~
loopbit
I'm of the same opinion. I love getting feedback, better if it's constructive,
but all kind of honest feedback is useful and welcome. And it doesn't always
come from people with more experience, sometimes a greenhorn will see things
that a greybeard like me doesn't.

But I've seen people giving negative responses to the best feedback. Hell,
I've had people complaining for hours because someone else replaced their
manual process that took an hour to do with a script (and copy&paste of the
result) that took literally seconds to run.

~~~
luckylion
Yeah, I've seen that as well. I believe it's mostly fear-driven, in a way of
"if this gets automated, why would they need to keep me around". It's a
terrible mindset for everybody involved. It really slows the team down, and
it's a major issue for the person themselves. It's like impostor syndrome on
steroids. Not only do they worry that they might be found out, they worry they
might be replaced by a script.

I've never personally seen somebody getting fired because a script can do
their job. I've seen them being freed from doing the same repetitive bullshit
day after day though, and finally being able to actually tackle new
challenges.

But unfortunately, that kind of mindset is not something you can change
through rational arguments, at least in my experience.

------
jrumbut
My perspective is that quality is a process and a project rather than just a
goal or a fixed property of a team. This new team is like a project that's
barely begun and you're coming off a project that was in maintenance mode.

So like any project it works best if you do one thing at a time and build up
some momentum. You can't fix everything at once.

See if you can get people to buy in to just getting the indentation consistent
(my favorite place to start), or preventing the development software from
touching the production database.

Get one win, give it a little time, and then go for another pass. Meanwhile
set an example in your own contributions. It is very possible to improve
things but it takes patience, planning how to deal with setbacks, flexibility,
and recognizing what the real priorities of the company are and what quality
means in context.

------
tjansen
I have been in both kinds of companies. 20 years ago, having none of these
basics was almost the norm. It can work, and sometimes I even miss those days,
because it can be fun and very fast paced. However, it also comes at a price.
There's a constant, high stress level because things break all the time, even
on production, and you have to be quick to fix them, often directly on
production. I wouldn't want to go back, especially not with a bigger team or
today's average developer and project complexity. And it sounds like you
already made your decision. Unless there are compelling reasons to stay (and
maybe try to introduce newer practices), you have learned a lesson which
questions to ask in your next interview (also google for Joel Test) and try to
find something new.

~~~
OldHand2018
> 20 years ago, having none of these basics was almost the norm

I guess I worked at one of the best then. It still went out of business.

~~~
tjansen
I just read the almost 20 year old Joel Test page for the first time in a long
while and I was surprised by what it didn't contain. For example, it doesn't
even mention unit tests. Which is no real surprise, because JUnit itself is
only 23 years old. Things like code coverage tools didn't exist back then. And
while there were some early tools for automated builds, like Mozilla
Tinderbox, setting them up was a real challenge.

~~~
ChrisMarshallNY
Unit tests are definitely plenty old.

I think that maybe folks aren't quite clear on what "Unit Test" means.

Nowadays, "unit test" means a test written into an existing test harness
system, like JUnit or XCTest (what I use).

In fact, I was writing unit tests for PHP-based Web apps and C++-based Mac
software more than twenty years ago. I just had to write my own framework.

Even nowadays, I sometimes write my own framework. For example on my
[hopefully] last PHP project, I designed a SaaS-type system, and eschewed
PHPUnit; mostly because it would need some special installation that might be
beyond the ken of the target users. Instead, I wrote my own test harness
system, and it worked great. It wasn't a crazy amount of extra work. I always
create massive tests, anyway, so it wasn't that big a deal.

For my Apple/Swift work, I rely on XCTest, which is a perfectly acceptable
test harness.

I'm pretty sure that unit tests were mentioned in _Writing Solid Code_ , which
is almost 30 years old.

------
Kagerjay
So I've been working with a lot of startup type companies recently doing
agency work

You have to sacrifice a lot of code quality and professionalism in fast paced
environments, its almost always better to under-engineer than to over-engineer

Here's my opinions

\- codereview - there's never any resources for QA. I just check teammates PR
if it builds and passes a few manual tests, then merge. I don't spend more
than 15 minutes on this. Coding standards highly depends if I've worked with
teammate before. Sometimes I disagree with something but still OK it anyhow if
its just me being nitpicky

\- Test coverage - not in early stages. If you use typescript it eliminates a
huge need for test coverage, but you'll still eventually want end-to-end
testing. Just not until production is near deployment

\- Normal development workflow - No tests, its a high opportunity cost, but
again depends on what software your building. I'd say 90% of apps don't need
testing early on

\- CI/CD - yes, its good practice to still use protected branches and specify
workflows for PR'ing and naming things

At the end of the day, you realize you have to cut corners and need to weigh
out the value proposition each tool set offers. As well as how your team
composition works.

Sometimes you have to defer tasks for later dates to revisit because its over-
engineering and things aren't fleshed out enough yet

The most important thing early on is elminating tech debt too. Each decision
you make is cascading. For instance code patterns you set today are going to
be used several months from now, ideally you want to minimize the need for
refactoring early on.

Write clean code with good variable names, and sane folder structures.
Likewise with sass styling etc. KISS (keep it simple stupid), just follow
those rules

------
jmchuster
No, i would say that your standards are quite reasonable. I would also say
that there are many companies that do not meet those standards. Usually they
have no excuse for doing so, just that no one there knows or most likely just
don't care.

There are also many companies that go overboard with their code review and
tests, get none of the intended gains, produce more slowly than they can,
because of an attempt to cater to the lowest denominator. But I suppose if
you're going to pick one of two extremes, that would still tend to be the
lesser of two evils.

~~~
Silhouette
_There are also many companies that go overboard with their code review and
tests, get none of the intended gains, produce more slowly than they can,
because of an attempt to cater to the lowest denominator. But I suppose if you
're going to pick one of two extremes, that would still tend to be the lesser
of two evils. _

I'm not sure that's necessarily the case. IME, not much will kill both the
pace of development and team morale faster than poorly conducted, heavyweight
code reviews, but one of the few things that will is a dogmatic requirement to
have some unnecessarily high level of code coverage in a test suite where
everyone is just writing make-work tests to get the number up.

~~~
planxty
Testing is a skill to learn like anything else. Teams that dogmatically apply
any new practice or process without making a genuine effort to learn that
thing will never extract value from it. If your team can try, fail, and learn
from mistakes, you are in a mature organization. If your team gives up quickly
because of fear of dogma or has no strategy for dealing with the challenges of
learning new skills, it's unlikely your team will ever extract value from
testing until the team culture itself changes.

~~~
Silhouette
IME, the problem more usually happens because someone in management read a
book and thought "I know, we can change our entire development process to do
this thing I just heard of and overnight my team will all become 10x
developers!"

If you've got a team that is genuinely interested in improving and willing to
work on new ideas to make the best use of them, both reviews and testing can
obviously be very helpful. That's not really the situation I'm talking about
above, though.

------
bizzleDawg
Eeek. Doesn't sound like you're being unreasonable in your expectations at
all!

I've been a small business owner, and a software contractor, so I've seen a
fair few medium/large python codebase of varying age and quality.

To address your points from the ~10 codebase I've worked on in recent memory:

\- Code review: Always in place, though often the CTO has a tendency to merge
without review on evenings/weekends

\- Test Coverage: Often a challenge - or rather tests are there for coverage,
but are of poor quality and don't really assert anything that useful

\- Your suggested normal workflow _is_ the normal. Sometimes there's been a
dedicated QA team that verifies the changes as seen by the end user too.

\- Deployment: Yep. Heroku or k8s have been common, but at least some form of
1-click deploy/promote

Perhaps I've just been super lucky! There are often still major problems in
the codebase and refactoring/rebuilding needed to address the challenges, as
well as resistance of the existing team to truly change their mindsets to
address the problem v.s. the band-aid (or instant gratification) of a quick
fix.

Don't give up the fight!

~~~
orwin
Adequate test coverage is hard without rebuilding from scratch. Hard to expect
in a big, old company. Except when a huge codebase have to be rebuild because
python2 have to be replaced (one of our software provider is in this case).

~~~
WJW
Out of all the items on the list (code reviews, CI, etc), it seems like test
coverage would be the simplest to improve? Assuming it has a test suite at
all, use one of the various test coverage scanners (simplecov, coverage.py,
etc) and check the output for a file with a low % of lines covered. Then write
one or more tests to cover the edge cases not yet tested.

It's a purely mechanical process unlike most of the other problems which
depend on changing the behaviour of people in different departments and/or
with more influence than you.

~~~
loopbit
Depends, code that was not written with testing in mind can be very difficult
to cover without some major refactoring.

Adding the first tests can be a slow and painful process.

Now, once you have those few tests? Yep! Add a few tests along the ones for
the new functionality every time you touch a piece of code or pick the low
hanging fruit every now and again and you can get to a useful test suite in no
time.

------
arichard123
The book "Working Effectively with Legacy Code" by Michael C Feathers is an
excellent book in which he talks about, amongst other things, a process of
selling the concept of proper unit testing to teams. And how he's managed it
in the past.

------
badpun
> I know how fast it is to develop when people write good code with
> discipline.

Interestingly, IMO writing good code with discipline is also slow (CI breaks,
code review takes forever, updating unit tests takes time, integration tests
take a long time to run etc.). The main advantage of disciplined process over
the cowboy approach is that, in cowboy approach, the code can become
unworkable after a couple of years, whereas with "mature" software engineering
there's good hope that the codebase will still be maintainable 5-10 years down
the road.

~~~
rileymat2
From my observations the payback is far quicker than a couple of years.
Unstructured with below average coders we are talking a mess in weeks that
becomes intractable without a lot of work.

------
Silhouette
Those seem like reasonable policies to aim for. What isn't immediately clear
is whether they are missing because of a lack of understanding or a lack of
willingness to change.

If it's the former and you've come into the small company with more experience
than most people there, you might get a long way and become quite popular with
your colleagues if you share the benefit of that experience intelligently. For
example, with the agreement of the senior people, you could show everyone how
to set up a good CI system or automated deployments, if that's something you
know how to do and they don't. These kinds of things tend to have obvious
benefits once they're up and running, but setting them up in the first place
can be a barrier depending on what else you're using, how everything you've
already got fits together, and of course the level of knowledge and awareness
of the people working on it.

On the other hand, if everyone is well aware that they should be doing
something and they know how to but just can't be bothered, that's a cultural
problem that you're unlikely to be able to change as the newbie. Probably no-
one else is either, unless they're doing it from the top down and have hiring
and firing privileges to force the issue by bringing in more people who expect
it and, if necessary, letting go anyone who stubbornly refuses to engage. If
this is the environment you're in, unfortunately putting up with it or getting
out are probably your only certain options.

~~~
snarfy
This has been my experience as well.

If it's a skills problem, by all means set everything up and be the hero.

If it's a cultural problem, run.

------
LatteLazy
In my engineering days there was a saying: you can have it quick and cheap and
high quality, but you can only have 2 of those 3.

Spunss like you work somewhere quick and cheap. That's not wrong per se. If
lives depend on the outcome, you need quality. But I worked in plenty of
financial places that were quick and cheap. Especially back office.

Ask yourself: would the organisation be better off if we were higher quality
BUT it meant we were slower or more expensive. If speed is more important,
welcome to spaghetti code land.

~~~
karatestomp
Skipping tooling & processes below a certain (not very low) point isn't doing
it "cheap and fast". It's saying "I want you to build my house but I want it
to be cheap so don't buy any more hammers, it's too much money and we can't
afford the time for you to run to the hardware store, just all share the one
hammer you already have".

It's doing it cheap (but actually expensive) _and_ slow _and_ low-quality.

~~~
LatteLazy
You really want to build that house and I respect that, but the client just
wants a tent and the hammer budget is zero. And since a storm is 10 minutes
away they're not wrong...

~~~
ju-st
And you can build a tent quick, cheap and fast. Getting customers to tell you
want they really need is the silver bullet.

------
kd5bjo
Consensus that these processes are really the best way to do things is
relatively recent, and I wouldn’t be surprised if there are a lot of shops
that haven’t yet retooled to them.

Continuous integration was only proposed as a concept 30 years ago, and was a
relatively fringe theory for another decade at least. Automated deployment
followed a similar path, but about a decade later. Manual acceptance tests, in
particular, remained quite common a decade ago even at the big tech giants.

------
mantap
It depends on the cost to the end user and the cost of failure.

At one end of the spectrum you have free-to-play games. You'd have to be
insane to implement a high test coverage on that. Nobody cares if Battletoads
Royale crashes.

On the other end of the spectrum you have safety critical software, financial
software, etc, where the costs of failure are very high.

Ask yourself "what's the worst that can happen if this fails?". Asking this
can also inform where exactly the tests need to be added first.

~~~
Cthulhu_
You mention f2p games, but those definitely need testing because they can
bring in money that most startups and other companies can only dream of. If
their servers go down / if the game becomes unplayable they stand to lose
millions.

But I guess there's plenty of games that don't have that kind of criticality.
Just mentioning a counter-example. (Personally I'm still salty that GTA Online
was released for free but the servers couldn't handle it, I mean come on, it's
a decade old, you'd think they'd have sorted out scalability and stability by
now. That game still earns its publisher hundreds of millions a year).

------
leothekim
Sounds like you’ve got alignment on these things at your startup but no one
knows how to make time for it. What have you done to step up and lead your
team out of the jungle?

I am not being flip when I ask this. I’ve worked at eight startups because
situations like this can turn into opportunities if you put your back into it.
Most of the work at a startup is about turning chicken shit into chicken
salad. If your team had it all figured out, it probably wouldn’t be much of a
startup.

~~~
chii
> turning chicken shit into chicken salad

and being sure to get paid for doing so (in the form of equity rewards). don't
forget that and let someone else claim your hardwork.

------
quantified
Is this a startup/young company or a more established one? “Enterprise”,
“consumer”, “b2c”? Some comment threads are related to a “publish or perish”
situation at under-resourced startups. If this is “b2b” enterprise, I’d
despair and look for greener pastures.

I am working now with a code base that was created during a time of such a
mentality, but it wasn’t true, just fashionable 8 years ago. So much of it
sucks, no functioning architect to ensure basic design quality or consistency.
Thankfully, for the first time in my career, I have management committed to
getting the worst bits in order, they seem to understand how costly all those
earlier “savings” were. Thing is, it wouldn’t have cost more to do it right
the first time. Engineers just would have needed to design correctly and
implement correctly. Which may have cost more eng $$ in the beginning, but
we’d also have had $MM more in referenceable customers as a result.

FWIW I have the responsibility of raising the quality via design review and
code review, as well as designing and coding. I’m one of those architects now.
Seems to be working.

------
codingdave
I'm surprised at the comments here acting as if change is not possible. Do
people really believe that there are 2 completely separate group of coders in
this world... those who "get it" and meet the best practices, and those who
reject those practices and fight to never improve?

I'd say that there is a huge middle ground of coders who want to improve, but
have business drivers that have stopped it from happening. And if approached
correctly, improvement is possible.

Overnight change is an unreasonable expectation. But incremental improvements
over the status quo absolutely can happen. You do need to approach it
expecting it to take time - storming into a dev team and declaring all things
must change won't go well. But picking one improvement, talking to the team
about it, talking to your leadership about the cost/benefit of making the
change, and then getting a consensus to make a change.... that should work.
Repeat that process, and not only will you improve the team over time, but you
will show yourself to be a leader and improve your career.

~~~
dustingetz
It's not the coders, it's the management. And sometimes it's not the
management, it's the business, which is the market, which is the customer.

~~~
codingdave
Do you have customers who want fast but unstable products? I don't. On the
contrary, when we talk to them about our product roadmap, they are more than
happy to wait for new features in order for us to improve the stability.

~~~
dustingetz
What if your customer is the government and your users have no choice in the
matter?

~~~
codingdave
My customers are 100% government entities, so I'm not sure what you mean?

------
nakovet
My suggestion as a candidate remember that you are also in charge of
interviewing the company you are applying for. Joel Spolsky had "The Joel
Test" and it was written decades ago This author tries to revise it:
[https://dev.to/checkgit/the-joel-test-20-years-
later-1kjk](https://dev.to/checkgit/the-joel-test-20-years-later-1kjk)

The interview is often seen as a one-sided interaction you are on the "I hope
they like me", and the company is like "can they do the job?" when in my
experience you should treat more like a date: do we have similar tastes, what
we have in common, where we differ, can we make this relationship work?

I don't think your expectations are too high, it's just that you as a
professional can work at most into what, 35 companies during your entire
career? If you stay at most 1 year on each company. That sample simple is very
small and not indicative of the industry.

Improve how you select your next job.

~~~
karatestomp
> The interview is often seen as a one-sided interaction you are on the "I
> hope they like me", and the company is like "can they do the job?" when in
> my experience you should treat more like a date: do we have similar tastes,
> what we have in common, where we differ, can we make this relationship work?

The more you manage to flip the interview, the better you're likely to come
across, too. 1) people like talking about themselves and what they do and will
like you more as a result, and 2) it puts them in a mindset of trying to
impress/sell-to you which does a bunch of stuff psychologically that works in
your favor.

------
crispyambulance
> ... this is what mid-sized companies are and I just have to endure and keep
> pushing.

For your own well-being and career happiness, I think you'll need to be
strategic about exactly how you "keep pushing" for change.

Changing habits in an organization is _extremely_ difficult. You can't just
provide a list of practices, make a terse case for each one, and expect people
to just say "Oh, I see, you're right, let me retrain myself on multiple
complex topics and then change everything about how I work, while at the same
time figure out how to explain all this to project managers."

The time scale for implementing what you call "the basics" in a workplace with
a dozen or so people is going to be more than a year-- at best, if you do
everything right and are people person with enormous leadership leverage.

Read about "Diffusion of Innovations"
([https://en.wikipedia.org/wiki/Diffusion_of_innovations](https://en.wikipedia.org/wiki/Diffusion_of_innovations)).
It's an arguably successful theory for how organizations implement
technological changes. It was originally conceived by social scientists who
studied how farmers (that's right, the agriculture industry) adapted to
change. The most fundamental aspect of putting this theory to work is that you
need to recognize and find "early adopters". Early adopters have two
characteristics which are important for spreading change: 1. they're willing
to try new things just for the novelty of it, 2. they're influential, others
look up to them as examples. If you focus you initial efforts on a very small
(even 1 or 2) "early adopters", that's the first step to success. There's a
lot more after that, like training and dealing with laggards (people who need
to be forced to change), but I don't want to type an article.

------
sadmann1
You can try and softly push towards better practices but if it's an
organisational issue you will likely fail. Your standards are not unreasonable
so it might pay to find a better company

~~~
machiaweliczny
I think you just don't want to work with people who accept such state of
affairs, so no point trying.

------
Tade0
_These setbacks are demoralizing_

It is, and after enough time you'll find yourself repeating the same bad
practices, because there are likely strong incentives in place for that.

In this case my question would be: are the products you deliver meant for
consumers, businesses or developers?

Because from my experience these groups have different expectations regarding
quality - here shown in ascending order - and require an appropriate approach
in each instance.

------
planxty
Cultural problems are hard to change. If you like your team, one option might
be to simply begin testing your own code and ask people to review your work.
Don't be overly optimistic, but from time to time the right person can create
enormous change simply by doing the right thing and patiently explaining why
it's helpful. It's likely your experience of mature engineering practices in a
bigger company is largely foreign to your colleagues, and they would enjoy
learning more from you, because you care about them and care about your work.

If that doesn't help, move on. Life is short and bad practices will be a drain
on your energy and your long term career trajectory.

~~~
wyldfire
> Cultural problems are hard to change.

Agreed, but the culture reflects the leadership. If leaders put up a backstop
and say "tests passing gate new commits and new commits should include new
tests," then the culture will bend to this. If leaders think that simple
process elements are negotiable, then the culture will reflect that.

------
thedevopsguy
Your standards aren't too high but I think you must realise that this is a
cultural problem with little hope of changing. Even if the push comes from the
CTO, it will take years for change to happen, it will require new hires and
bringing new blood into the engineering leadership.

If you do want to take the challenge (which I strongly discourage you from)
you'd need to collect data to build your case, quantify the time and human
cost from issue/jira to code landing in prod to number of incidents/bugs. The
instrumentation to do this will be a fairly chunky piece of devops work. Frame
the data in light of your competitor's ability to iterate their products and
so on. When it's collected and presented it can be quite compelling and people
will listen.

It's only at this point you'll be able to present the problem to management in
way that they understand. You know and I know that this is a cultural problem
first, then a process problem and lastly a technology problem. The amount of
work to effect this kind of organisational change, even in a small engineering
company is immense. I don't know your motivations are for staying, if it's the
domain or the money but if this something that bothers you then this is the
best piece of advice I can give you:

Run, head for the hills, and don't look back.

~~~
majewsky
> this is a cultural problem with little hope of changing

I disagree. Most existing teams with good processes started out decades ago
without them, and improved incrementally from where they started. Team culture
can absolutely be changed, but it takes a lot of time (and requires
cooperation from seniors and managers).

------
smonff
I've worked in places where people cannot understand the necessity of most of
the things you list.

If I don't do those steps, they are fine with it at long as it works. If I
want to setup all the minimal stack, as long it don't multiply the planning
per 3, they are fine with it.

I think it is extremely discouraging, because even if you do all those good
steps that would surely improve the product quality overall, it is not
something that people can see or will consider. This is not a thing customers
can see. Things will just work most of the time, and in case of a problem, you
will be able to fix them in no time and it will go back to normal fast because
you built all the toolkit before. Customers won't even have the time to
complain.

Your standards are highly reasonable, but if you ask some sales person if you
should spend 5 days on a feature or 7 days with better quality and full test
coverage (ok it would be more like 10 days), they will always say _no, don 't
do it_ or _it 's fine, we'll take care of this later_.

 _Documentation? Oh, you 'll do this next summer._

Explaining why you should do all this to a team is a long term work: it can
take one to two years before they start to understand what the hell you are
doing (I mean, maybe you'll have better results than the rest of the team or
your infrastructure will be somewhat a little bit more stable).

But it is extremely discouraging, keep yourself warm and don't get too tired.
Just do the things the way you are used to do and try to setup the things that
are missing so hopefully one day other people will want to use them too.

------
rrmm
Your standards seem to make sense. But I suspect there is _immense_
variability between different companies.

You should I believe push for changes with examples of good development
practice. Start with easy things that can have impact, and hope the
improvement in quality of life due to better practices will stir more interest
in improving their process.

But if you have to be the jerk about everything and people just end up
resenting you for it, well I think you know what to do.

good luck.

------
golergka
Usually these trade-offs that logically follow different priorities. With a
large company, it's important not to break things. With a small company, the
speed of iterating and moving things forward can be much more vital from a
business POV.

However, if you say you're confident that

> I see how slow dev is

it's just crappy quality and not a trade-off, as I would assume in a usual
case.

------
InvOfSmallC
I think that you should bind your standardS to the business. What you said are
absolutely best practices recognized on the Accelerate book. But they also
require time and effort (well it really depends, you can have everything
deploying an app on Firebase using GitHub CI for example and run the tests).
Do they actually change the cost of delivering in your case? Are you actually
able to demonstrate what is the gain? Also? Do you have a market fit? All of
this is not really important if people are not using the product. In short I
think engineering standard are important but they always need to be put in the
context you are working. If I’m opening a startup I need to test my product
with customers. I will probably need to change the UI and the business logic
many times. I could not care less about proper automatic testing in this
phase. Once I have the product then I can get worried about engineering best
practice.

------
zaphodias
I read your post and: wow that's EXACTLY my situation!

It's also a lot disappointing to me that I can have a very basic CI on my
github side projects done in half an hour at most, while a company with some
great devs in it can't.

I'm not talking about "use this new technology/framework here, blabla". I'm
talking about me having to fix regression bugs because no one didn't (or
couldn't) write small unit tests on the critical parts of our infrastructure.

As you also said, everyone I spoke to, including CEO, agreed that we are less
productive due to this and a company culture shift is needed. 6 months in I
still have to see any change.

Plus: I'm not in a small startup that needs to ship something fast. I'm in a
smallish company with almost 20 years of experience. They did somehow fine
until now, but they're struggling to scale up.

------
rentonl
This is an interesting conversation and one I think about a lot myself. I
currently work for a large-ish company with "quite good" practices, and I
often wonder what sorts of policies other companies implement. As you grow in
your career and continue to join teams that were better than the last, it's
sometimes hard to know if your standards are a product of your career
trajectory, or simply a product of the times.

However, I do think there is some mid-ground between what you are used to and
what the company currently does. In my opinion, these are the minimum
requirements of what a mid-sized company should be doing:

\- Version control. No excuses here.

\- Code Review. This needs to be done.

\- Test frameworks are setup and make it easy for a developer to write and run
tests. I wouldn't necessarily get hung up on coverage, but large features
should have tests in the PRs, and there should be a good culture of testing
within the company.

\- A CI pipeline that fails the build if tests or linting fails.

\- I wouldn't be too concerned about automated deployment from the CI. This
also depends a lot on the type of product. It's much easier to automatically
deploy a b2p application than a b2b one that might require proper release
correspondence with clients beforehand. I think the minimum here should be a
system to handle provisioning and deploying to boxes (whether that be
something like ansible or in-house scripts).

I'd be interested to know what others think the benchmark should be for mid-
sized companies. One last point: You are in an excellent position to make
changes within your company. If the truth of the matter is that your
colleagues "just can't imagine another way", then you can work with them to
try to get some of these policies implemented. If you can convince them that
there are actual benefits to doing their job a different way, then I think
they should be receptive. You can come out of this job knowing that you helped
level-up the developers and left the company in a better place than when you
started.

------
serkandurusoy
Your expectations are neither unreasonable, nor reasonable, without the
context and environment of the business and market it operates in.

For some products, companies and their markets, the expectation from the
users/customers could be so low that the mere existence of the product can be
quite disruptive.

In fact, (most) startups exist to pursue an idea of disruption.

As the product, company, market and customers evolve, the expectations begin
shifting.

This leads to an inevitable choice across a spectrum from leaving things as
they are to rewriting entire stacks.

If the leadership can do a good job hiring the right people to both navigate
the chaos and know how to get to a better place, things would then evolve, in
whatever pace that can be allowed by the business, given calculated risks on
engineering practices or lack thereof.

The key here is the "right people", rather than just "more people".

Based on the information shared, you sound like you are the right person to
lead an engineering quality and reliability initiative.

Although, I do assume that you may not be the right person because you are
failing to cope with the current chaos.

That being said, the mere fact that you're seeking counsel here tells me you
are willing to manage this. I think that's a great start.

At this point, I belive there are two (and possibly more) things you can do:

\- Talk to the key people in leadership to understand how they perceive the
current situation and whether they are willing, if not even intent on,
improving the status quo.

\- Ask yourself for how long more you can navigate the chaos and whether that
takes away from your mental and even physical well being.

Perhaps shifting your perspective and being intentional about it can help.
This could even be the best thing that happened to you. Fast forward a few
years, you'll perhaps have become an engineering leader who has had the
opportunity to have experienced a huge paradigm shift and worked on solving
its challenges.

------
tarsinge
I depends from what you derive your satisfaction. I've been at a company that
had perfect engineering practice and was completely failing because engineers
were almighty and oblivious of business. That was demoralizing. A useful
product makes me more happy. Code quality is not an absolute end goal. Sure I
would prefer to have both, but in reality it's usually a tradeoff, and over-
engineering is worse than under-engineering when in doubt. Also I've seen
shitty over-engineered (edit: from a user experience perspective) monstrosity
with very good "code quality", and hand-crafted delightful to use apps that
would not check much on your list.

------
peelle
I work for a small company that's been around for 20+ years. All of those
things you outlined as basic, are things that I have been fighting for the
last eight years. I've won a few battles, compromised on a few others, but
lost most.

In my opinion your expectations are too high for a small company. Most of the
people I have worked with at small companies don't have experience with most
those basic tools. Some actively are afraid of code reviews, and others see
tests as writing the same code twice, hence a waste of time.

Management and coworkers pay lip service to wanting these things, but I've
found that they see them as nice to have extras, and not as time saving
efficiency increasing tools.

Don't get me wrong things can change. One way I found is to overwork myself
and implement it outside of my normal projects. Then I just have to keep
pushing and educating people to follow along. That's how I got the majority of
our code under revision control.

The other way is that management finally has enough of a problem and someone
convinces them one of those basics will make things better. In our case
managment got tired of making new features live, and finding out afterwards
that something else had regressed. That's how we got end-to-end tests.

Company culture can change, but it'll be slow. Try and frame things in a cost-
benefit light for management. For developers try and show them how it will
make their life easier, and show them the cool factor. Good Luck!

------
yingw787
I'm on sabbatical right now because I get how frustrating that can be. That
being said, maybe me sharing some points about my sabbatical can help put
things into perspective:

\- It's taken four months since my project (a personal-use hybrid OLTP/OLAP
streaming BI framework) has started, and I'm only wrapping up the development
now. I'm fine with this because I know what I want and I don't want to deal
with users while things are in flux, but if this was a business, I'd be out on
the street by now.

\- Engineers are paid well because there's not that many of us. It's not
because we're important. Sales is what brings home the bacon, marketing kicks
off the sales funnel, customer support closes the sales loop, product
management translates sales' requirements to engineers...and engineers just
build the thing according to requirements. Many one-person startups don't have
engineers, or even anybody technical, they just use no-code tools and pay
contractors and they do just fine.

I'd consider broadening your options in order to grant yourself more agency,
especially paid solutions that you can form a demonstrable ROI-based argument
for. Terraform may seem like a bit overkill, esp. if you don't have serious
cloud charges. Maybe managed APIs as a service makes sense, like Netlify, that
have CI/CD and can spin up various apps for money. Then you can say "for $25 /
mo. we save X developer hours, which @ market rate saves us $XXX per mo. which
increases our runway by this much."

------
ThomPete
In Denmark we have an expression "fagidiot" loosely translated "idiot of your
field".

A soldier who can't enjoy a war movie because their use or the sound of the
machine gun is wrong.

The designer who can't stand the product because the typography turns them
off.

This tendency to think that your field always needs to be applied to extreme
perfection.

Anyone who want to know where the line is should try and launch a company
following the "fagidiot"'s principle and see how likely they are going to be
successful.

------
yizhang7210
I've experience very early stage startups and I've experienced medium size
(400 dev) company. To be completely honest I don't think these practices are
necessarily functions of company or engineering team size.

I'm convinced that there are startups that have good practices and there are
big companies that don't (and vice versa), so I'd say it's more about this
particular company rather than all companies around that
size/location/industry or whatever attribute.

On a practical note, I think you have a few choices. 1\. Leave and join a
company with better practices. It's a safe choice. 2\. Take it as a challenge
and be a change agent at the current company. Good practices have value. Teach
them. Bring them in. Negotiate with managers and people above, try to convince
them to adopt to better practices. This is hard, really hard, but you'll learn
a lot from the process, and you'll be a hero at your company if you succeed.
3\. Do nothing. Get frustrated and complain. Sink into the same level of
mediocre/bad practices just like everyone else. I don't recommend this one.

------
shay_ker
As with anything in Software, there's a tradeoff. "Code Quality" and processes
have tradeoffs around risk, i.e. is this going to break something in prod?

If it's a real small startup (< 10), and you're pre-revenue or there's a bunch
of emergency situations, then yes, a lot of what you're describing is normal.
Things are crazy, and you have to cut corners to even make money.

If it's bigger than that, then you've got a problem and you should start
looking elsewhere or attempt to change the company from within (hard to do
unless you're in leadership).

Otherwise, here's my personal rules for "running scrappy":

\- Pushing to master & prod w/o review is fine if it's truly an emergency or
something super tiny, i.e. a whitespace change. Otherwise, it's good to get in
the habit of putting up a PR, even for posterity.

\- Connecting to prod dbs - never do this unless it's something you have to
fix right now. Otherwise, just grab a copy, a backup, or connect to an idle
follower instance if you need prod data (v ez to setup).

\- Bad code is fine. You have to pick & choose your battles. Ideally care
about stuff that's around building a mental model of your application rather
than quibbling around refactoring some small function

\- Similar note about testing... you can get away without it in a bunch of
cases, especially if the app is easy to QA locally

\- Deployments.... just use Heroku :-)

\- It's good to spend at least a little time architecting/designing, but
seriously time-box it and run with what you've got

\- Staging environment.... you won't have a good one for a long time :-)

------
ian0
I agree that your demands are unreasonable for a small company. It's like a
person getting kitted out in full tour de france gear to ride their bicycle to
the local shops.

However there is a time and a place. Smaller companies typically havent
reached the point where they have both the time and driving need to improve
processes. But they will eventually. And when they do they need a person who
is able to implement it, like yourself.

I think its great that your concerned about it, that your eager to improve the
processes. Dont be disheartened by the fact that its hard to make people
change behavior - its normal. You can do it though.

Its important for now that instead of seeing it as a general team-quality
issue, you look deeper and tie your improvements to things that are critical
locally. Eg. if pushing to production is causing issues quantify it, explain
it to folks and get their buy in to implement the process.

This kind of direct "immediate problem solving" approach will likely fly
better than filing initiatives under the boring banner of good practice.

------
lawik
Your standards seem fine. But for a lot of companies the initial techies set
the approach and a lot of people find the thoight of these practices stifling.
Not necessarily in practice but it can sound very heavy. I'm self-taught and I
have a fairly sizeable mismatch with enterprise OOP-focused engineers when it
comes to testing, overhead and process.

I think it's hard for people to appreciate thw other side of these argumenta
without having lives through some consequences. I firmly believe in automation
and testing. I believe tests must be pragmatic to not be overbearing. I mostly
believe in code review for teaching. The research covered in the book
Accelerate (subtitle something something devops) made a strong case against
code review and change control for most software development.

So yeah, your standards sound reasonable, if maybe a bit much for my taste in
some aspects but I know lots of shops that wouldn't be anywhere near. And this
is a skillset and know-how you can provide. Hope that's a useful perspective.

------
mercer
As others are saying: it depends.

Without knowing more about your situation and its context within the larger
org, it's difficult to make any judgments.

All I'll say is that I've internalized all these best practices and yet here I
am running various products on various VPS's with a git post-receive hook and
then logging in to the servers and recompiling or restarting. I have no tests,
the code is not properly commented, and I've only written typespecs (Elixir)
for the crucial bits of some of these apps, and I truly believe I've made the
right decisions.

In recent weeks I've pushed for refactoring, and I managed to get some hours
to work on a better deployment strategy. When more money becomes available
I'll push for writing tests and working on documentation. The goal then would
be to remove the 'bus factor' of 1.

I imagine you're nowhere near this particular scenario, but I imagine you're
on a scale somewhere and I hope you figure out what the right standards are
for you.

------
bradfa
This is an engineering leadership problem. Your new company does not seem to
have an engineering leader who understands the cost to the business of having
the engineers act the way they currently are. I don't think you have to run
away, and you don't have to become such a leader yourself, but you should talk
with your leadership and show them why what the team is doing now is not good.
Make sure to first understand what your leadership values, then present to
them better ways of doing engineering where you show the impact it has on the
things they value.

So like for automated tests if the leadership currently thinks that test code
isn't actually doing anything for the customer so why should it be done? Then
you have to show how much money/time/whatever has been spent by engineering
fixing the same bug over and over because you lack regression tests and
compare that to how much would have been spent to write a test case for that
regression.

------
agentultra
Do one thing at a time, well, and track outcomes.

Be prepared to take responsibility for it.

Code review is a practice that has studies which demonstrate that it's
effective at reducing errors in software [0].

Work on that at first. Be prepared to spend a good amount of your time doing
most of the code reviews. Write a review guideline with your team and share it
around. Once people get used to the habit start encouraging others to take
some of the responsibility.

I encountered a similar situation. Nobody practiced code review. Test coverage
was spartan and brittle. The company was focused on shipping the first thing
that worked, fast. Maybe it was to keep the lights on and land those precious
contracts... but it had the external effect of tightly coupled systems,
increased error rates and support requests, and in some cases errors resulted
in customers losing data.

When changing culture and habits you have to be patient and resilient.

It took about a year before code review became widely adopted on the team.
About six months after that we started tracking our code review metrics as we
found that pull requests with few comments and large amounts of change were a
big risk. We started getting feedback from reviewers that changes over a
certain size were slowing down our velocity so we started seeing people submit
smaller, leaner changes.

I did the same thing with testing. We now trust our CI pipeline to manage our
code quality and releases. We're working on CD. It started small. And it grew.

You're not unreasonable. And neither is the team you're working with. Manage
expectations and be the change you want to see and be patient.

[0]
[https://sail.cs.queensu.ca/Downloads/EMSE_AnEmpiricalStudyOf...](https://sail.cs.queensu.ca/Downloads/EMSE_AnEmpiricalStudyOfTheImpactOfModernCodeReviewPracticesOnSoftwareQuality.pdf)

------
lewisjoe
I've worked for both types of companies. It's surprising that both cultures
work in their own context.

At the startup I worked where the dev process was zero, we were able to flesh
out pivots and products at a pace that was able to bring continuous
investments to the company. To be honest I didn't enjoy the craft though
during that time. There was no depth, but a lot of breadth. It was just about
churning out code like a machine.

At the bigger company where I work now, money stopped being a factor. I was
able to afford time to ask fundamental questions about my code. My code was
reviewed and shipping was governed by a process that scrutinized devs. Slow
and sometimes frustating, but still enjoyable given the freedom of time I was
now given.

At any day, I'd pick working for a large-ish company than a early stage
startup unless it's a startup that makes things I care about.

------
myth2018
I've faced situations like yours. Your expectations are totally reasonable
IMO, but, in order to promote a significant change at the current company, you
may have to go through a probably long process with many layers of human
factors involved.

I don't feel myself in a proper position to give you advice, since my
experience is limited. But, some things I've seen working:

\- identify whether there is a "dominant group" that enjoys some sort of
political influence and are trusted by the direct manager. This is important.
They are usually the oldest ones at the team and, as they got trust and
respect from the management, they also got out of the pace with good practices
applied elsewhere. Be careful with them, in case this group exists, because
they won't let you proceed with such "disruptive" ideas risking to make
evident that there's always been a better, more productive way, but they
haven't applied them for pure inertia.

\- if you have the opportunity, and think it's worth the effort, try to deploy
or build some small tools/processes/etc and show them. That will be very
eloquent examples;

\- don't be concerned about taking credit. Everybody is interested on being
more productive, but human emotions will always prevail over any rational
need. I'm proud for having built some productivity tools in use for 15 years
now in a company I've worked for, and almost nobody knew that I was the
author. The "architecture" team wrapped them up on a asp.net web app and took
all the credit. That's fine considering I achieved a more important goal. If I
had attempted to bypass the architecture team and promoted my tool
independently, it would probably have not been put in use.

And always bear in mind that this is usually a long term effort and you have
to continuously assess if it's worth. Maybe other non technical aspects
counterbalance the issues, maybe not. Some of my happiest years were spent
working on legacy, terrible code. But this is a very personal and multifaceted
decision.

------
kmarc
Yes, your expectations are too high.

I'm trying to hire a devops engineer. Applicants have the shiniest CVs with
even 10 years of devopsy stuff on it.

Then I ask the following question: "Explain me the relation between a VM,
linux container, docker containers, kubernetes pods. Whatever you find
important"

And they have no clue.

------
tnolet
Your $current_company needs the reality check.

I run a 4 person dev team at my tiny 8 person startup. We kinda do all the
things you mention. CI, reviews, auto deployment. Our test coverage could be
better but is increasing by the day.

What you expect is totally normal.

I bet the current co has weak technical leadership

------
Karupan
These don't sound unreasonable. I've been in a similar situation before. In my
experience, if the culture in the org is generally positive, it is worth
taking the effort to champion good practices. You can become the go-to guy for
setting these standards. Future developers will thank you for having done so.

However, if you think the culture is not conducive to positive, large scale
change, it might end up being a waste of your time and energy. Having to
constantly say no, and ask for everyone else to fix stuff in PRs can be
exhausting. There is also a real risk of others perceiving you as someone who
always finds faults with everyone else. That is a hard tag to shake off.
Balancing that is the real challenge.

------
frellus
Your larger company built up those things over time, but likely with
management support and pushing and enough of it built into the culture that
everyone realized the value.

In your smaller company these things need to be done, and you need to be a
champion of them. Pick your battles, but don't assume you can win every one at
the same time. Pick the one most important to you or would have the most
impact, champion it, and lead. You've seen nirvana, now you might just have to
lead people to the promised land.

Just don't be one of those people who are like, "When I worked at
($current_company - 1) everything was much better than here. No one here gets
it." Be the solution.

------
JoeAltmaier
Counter these examples with small companies paralyzed by process, introduced
by well-meaning hires from large companies with plenty of capacity.

A large company is a marathon run. Discipline, strategy, training matter.

A small company is running from a bear with your hair on fire.

~~~
izacus
Except that lack of some of these basics makes small companies extremely hard
to pivot and modify their products for larger customer base - pretty much
cementing their fate as a failures.

Even small teams of 3 people can benefit from basic code reviews and CI
pipeline that makes them significantly more capable of responding to new
business requirements than startups bogged down in 5 months of technical debt.

~~~
JoeAltmaier
Sure its dangerous. But the question was, why is it so chaotic in a some small
startups?

And you can't have everything. You can insist on process all the way to
bankruptcy. Whatever the risks, sometimes the one that succeeds is going full-
on to the finish line.

------
MattGaiser
> but with the slightest bit of pressure those principles are gone

If this is pressure from above, there is little you can do. Employees have one
overriding requirement and that is to keep management happy.

Management clearly didn't care about any of this before and they evidently do
care about speed, so what are employees going to prioritize?

Also, testing and code review are better at producing bug free features. Most
managers I know aren't counting the bugs as part of the feature but rather as
an additional feature. Past bosses would be happier with me if I delivered a
buggy feature in a week and spent the next week fixing it rather than
delivering the feature in 10 days.

------
jonnypotty
Make your peace with working in a slightly crap environment or get a different
job. It will be hard for you to produce anything good and if you do it'll
probably go to waste. These issues are signs of deeper issues.

Good luck bud. For both of us.

------
l0b0
Nah, entirely reasonable. We do all of that and more at the current project
and the client has been super happy with the result all the way. We've been
able to keep the tech debt low enough that we're just chugging along at the
same velocity two years since the start (to the point where we've got the
attention of the CEOs on _both_ sides). Just don't expect to change company
culture within a reasonable time frame. If you can't take it (I know I'd be
out of there if they wouldn't even give it a try) just look elsewhere - plenty
of places have reasonable processes in place.

------
asmosoinio
I don't think your standards are unreasonable.

Good practices pay off in overall being able to produce more _correctly
working_ code. Even if in the short term it feels like for example writing
unit tests "slows you down".

------
morty_s
I’ve found myself thinking similar thoughts (as OP) at a startup I joined. It
seemed like no one valued code quality, yada yada.

If the things you value are valuable in your new environment, you’ll find the
tact, time, and patience to improve the codebase.

One thing that helped me was helping others. Writing documentation,
documenting processes, playing dumb sometimes...

Your standards are _not_ unreasonable, but they are _your standards_. If you
want others to adopt them, you must lower the cost for them to do so—and must
do so in a genuine way.

Lately, I’ve found the quickest way to be “right” is to allow others to be
“wrong.”

------
cjfd
Your standards are very reasonable. You should keep pushing for higher
standards. Preferably these also should be enforced technically. I.e., it
should just not be possible to push something to development without code
review. At first you can also just make sure you have good quality in the
parts of the application that you are working on. It will at some point become
quite noticeable that thing are going better there. I.e., the tests will catch
something that would have otherwise failed in production. This can work as an
eye-opener.

------
mcv
Sounds to me like your standards are fine. Pushing straight to production
without code review or tests is only acceptable if you're new and nobody is
using your product yet.

When you're still in the prototyping stage, you want features and proofs of
concepts, not waste your time on infrastructure that's going to change in a
week, or tests for code that's going to be completely rewritten two weeks from
now.

But once you're in production and you're starting to have a user base, code
quality matters. It's worth investing in.

------
wolfspider
I’ve been there before and you will be lucky to change just a couple of those
deficits within the timespan of 2-3 years. It’s still worth pursuing but just
make sure that the organization is willing to take it on like an actual
project and not as an extra hobby you yourself are working on. The first place
to start is buy-in from the other devs and most likely that will be the most
time consuming and frustrating part of the whole endeavor. Work on it together
from the perspective of reducing tech debt.

------
niuzeta
One word: _Prioritization_.

Your standards and expectations are reasonable, but sometimes push comes to
shove. You're describing a lot of intentionality of the seniors and
management. Ask. Communicate. Share your concerns. Accepting the vast distance
between the ideal and the reality is part of engineering. Bridging the gap is
the other part.

I sympathize with your frustration, but no ideal place exists. My old team
tried their hardest to get to the state you're describing for two years and
got there. It was beautiful.

------
mamcx
> In $current_company, I was surprised that none of the basics were there. All
> agree to do these things, but with the slightest bit of pressure those
> principles are gone

This is the normal. I think I have never be in a project with the "proper"
stuff from the start.

I have applied what I can, not even asking (because the answer will be "no?"),
so the fact that:

> All agree to do these things..

You are set! that is the key!. Now, how do this successfully?

Pick only 1 thing to solve (like I say, almost daily, to Stakeholder of the
projects "One problem(or miracle!) at time").

The first is "use source control" OR "use a task manager/bug tracker".

For a project with more non-developers, the second will be MORE useful.

The key is use the most simple thing you can get. I use pivotal, ignore it for
all the SCRUM stuff, and only use it to list the task to be done, task doing
and done, and train everyone with this ONLY rule "Put what is more important
from top to bottom".

That is literary, the only process that I use with others. With non-
developers, I not even try to expect them to label correctly bugs vs features,
and most of time I rewrite the task myself (for clarity).

But man, people, specially non devs, love to see the progress of the project!
This relieve so much presure is insane.

So the key:

* Pick only 1 thing to improve at time

* Use the more simple tool/process possible

For example, use git, only 2 branches (master, dev)

* Accept some imperfect inputs from people that are not skilled in the trade

"My users will never reporte correctly a bug, so I rewrite the reports after
talk to them"

And for others "the devs never put a good message in commit", then

* Pick only 1 thing to improve at time

if are in the phase of "at least using git!" not sweat it. Maybe gently
remming them

And probably:

* Have a mega list of good things to do in the task manager, and cross milestones with the team. Celebrate when done!

------
exdsq
All of this sounds like something you should expect except perhaps point 4, I
don't think deployments _need_ to be automated and with infra as code although
that is a nice thing to introduce. I'd push for the first three points to be
mandatory though, there's no good reason (except maybe in a 1-3 dev startup)
to avoid them.

However, don't see it as demoralizing, see it as a way to teach other
developers good practice and have a huge impact on the businesses engineering
practices!

------
manuelfcreis
I would say your standards are very reasonable and should be implemented
across the board.

In my experience it's very easy for company culture, namely in smaller
businesses, to get the impression that code quality is a luxury rather than a
necessity. And it's even easier to have good intentions, but due to a lack of
cultural enforcement just keep them at intentions and never implement
anything.

So I would say that you either try to get your standards across or learn to
live with lower standards .

------
fernandogrd
If the business don't see the value of those things, you're more likely to
convince them if you can prove how those things can actually save/make money.

Some pointed out things like retrospective on outages, but there are other
things, like how testing could reduce the number of bugs, thus, reducing
context switching and debugging times.

You could even tight it directly to money by measuring what a bug cost and
make a experiment in a team showing testing reducing that cost over time.

------
rb808
Junior engineers can't change culture, they'd there to learn. Mid ranked
engineers can improve culture by changing parts directly and encouraging
others Senior engineers can hire and fire to get the company to work their
way.

Presumably you're midranked. If you are trying and its not working you either
need Senior people on board or you learn to live with what you have. Do the
best for your work and try to show the improvements you've done.

------
NicoJuicy
It depends on how large the company is.

Are you doing it on your own, you'll probably won't need unit cases because
you know it from the inside and out. You also know what to test.

Larger companies and eg. Distributed companies are code-meshes. Everyone works
in most of the code. You need code-relviews.

And smaller companies are in between. They aren't sure yet which road to take.
You will have to do the grunt work if you want something to change

------
xwdv
Always remember, you are not there to make code better or implement robust
processes.

You are there to _make money_. Or, if you are working a lower tier job, simply
_reduce costs_. If you are not doing one of those two things as a developer,
your job is in grave danger and you will be the first one cut.

Throw your standards away, your standards are the company’s standards now. If
you want to preach standards go be a consultant.

~~~
UK-Al05
Trust me. You can make a lot of money for the company by improving the
companies standards.

------
_benj
There’s a lot of talk in this post about “experienced engineers” but it is
never defined. I wonder what does an “experienced engineer” has or how can a
junior acquire those skills.

Personally I have about 8y experience but suddenly found myself as CTO
(inflated title...) of a startup, with budget to allocate, processes to
implement and weighting what to hack together vs what to implement properly.

------
JamesBarney
To expect any company you work at to follow these standards isn't
unreasonable, but if that's what important to you in a job, you have to ask.

It is unreasonable to expect every company to follow these practices.

Also you have to realize that these practices don't universally increase
development velocity. Code review, high levels of unit test coverage, and
deployments take time.

------
sbmthakur
This looks like a cultural problem where the top brass either believe in
strong-arming developers or aren't aware about the dreadful impact of not
following processes (code review etc.)

Your expectations are perfectly reasonable. I think you should consider
explaining to everyone (including non-developers) how bad things can go if
these practices continue.

------
jupp0r
You have reasonable assumptions of a minimum quality level. Looks like you
botched the “Do you have any questions?” part of your interview there. One
indicator I’d look at when making the decision to stay or walk is the people
that are hired. Are they feeling the same way as you? If not, you might have
accidentally ended up in a sweatshop.

------
whateveracct
You have to be able to sell the value-add of all those new processes and
justify their very real costs. Take ownership of things you want to change and
make it as easy as possible for others to follow. The right thing should also
be as easy as possible. Lots of fixed costs to pay along the way!

------
0xfaded
Another issue is agreeing on that bare minimum. I'm okay with shortcuts, but I
need a clean git history as my mainstay to understand how the mess happens.
Other's think that managing branches is a waste of time :(

------
jhowell
If your interest is organizational change around best software development
practices, you should stay.

If you interest is in writing a lot of code quickly, "this is frustrating
since I see how slow dev is", you should leave.

------
mbrodersen
Making short-term-good-long-term-bad decision might be the right thing to do
for a small company in order to survive long term. However nothing stops you
from doing the best you can given the circumstances.

------
f1gm3nt
I use to work at Salesforce/Pardot for about a year. They had A LOT of
security in place (VPN, 2FA, etc.) and were managed very well. Deployments
weren't automated but everyone that had code in the deployment had to be on
deck in case shit hit the fan. I learned a lot working there and having them
drill security into my head I was able to use that in future organizations
that I worked at.

The startup that I joined after that had passwords stored in plaintext via a
google spreadsheet. Code was not stored in VCS and updates were done in
production. I helped the organization adopt scrum and added some development
processes in place and added tools to help me and the small team (me +2) of
developers manage the different codebases a little better. No one wanted to do
this but I forced it anyway.

The organization I'm at right now was similar but has a lot of different
challenges.

Each organization you join will be different, the culture will be different.
Some will be focused on quality and some will not. You need to understand a
few things and be able to communicate with executives and/or managers to
accomplish your goals.

Executives do NOT GIVE A SHIT about automated deployments, code coverage, code
reviews, etc. They view those things as wastes of time and the "code monkeys"
should just get back to work. I'm not saying this is the case 100% of the
time, but you need to change how you communicate with these people. Explain
what tech debt is and how small investments in time can reduce this. Yes,
going from 0% code coverage to 80% is going to take time, and this is
something you will need to explain to them.

Some devs are similar and I think that's mostly because no one sticks around
long enough at a company to maintain their shit code.

Depending on your role you are either in a position to force these things to
happen or you are in a position where you need to bring others up to your
level. Both are difficult in their own ways and will require a large time
investment on your part. However, BOTH will require you to help others raise
their expectations.

The other thing I want to leave you with is a conversation I had with a mentor
a long time. Being in a similar situation he told me to not hold others to MY
expectations. Hold others to THEIR expectations. This comes back to helping
others improve. Bring others UP to your level.

If none of this helps, you may want to quit and find another position
elsewhere, but keep in mind, this will be something you are going to run into
in many organizations and you are going to have to learn to deal with it.

------
ravenstine
You you want code review and testing, then start looking for another job right
this moment. It doesn't matter whether the company has a right to crappy-but-
working code. They are probably not going to change their standards until the
situation with their software becomes untenable for them, so I wouldn't hold
out hope that things will get better in X years.

In the mean time, see what standards you can implement without their
permission. If you can fit some tests in there without sacrificing velocity, I
see no reason not to add them. What are they gonna do? Tell you no? That will
be a litmus test for whether you have any future with these people.

------
jfitzpa22
Welcome to the world of well versus poorly run companies.

------
jcampbell1
I have no advice because you never mention anything about the customer.
Reframe the argument if you want to be persuasive with the powers that exist.

------
itbeho
I've worked for a large number of startups where the quality of code was
inversely proportional to the amount of profit the company generated.

------
thefuzz
Would you say its good practice to ask specific questions to uncover the
problems mentioned in the OP at the interview stage?

------
sergiotapia
Your expectations as described are not high. CI/CD is a bare minimum unless
you're working at one of those jobs where tech is just not a main concern.
I've worked at some places like that, while the job was utterly chill and
relaxed, you don't grow professionally. If the company tanks, you're toast.

That's all I have to say about this: If the company tanks and you forget about
good practices, you're toast.

------
GoblinSlayer
Why frustration though? Those things are funny. There's even a joke "I
accidentally the database".

------
Glyptodon
I just ended up in a new position to avoid furloughs and I'm feeling similarly
to you.

------
mattlondon
When I first entered an environment with CI and code reviews as a junior, my
thoughts were "OMG I am going to get _nothing_ done now - it is going to take
_forever_ to do anything!".

And I was right to a degree - before I could pickup a bug, fix it, and it
submit to the main repo without any fuss or review within 5 to 10 minutes and
it would be in the next release. Knocking out bugs was a dream - done! fixed!
resolved! done! done! done! DONE! project managers loved it as you could just
machine-gun through fixes. Afterwards my personal velocity slowed right down
and it felt very restraining.

This freedom and simplicity to do what is needed for developers is _super
seductive_. If you come in as someone new to a team and want to start taking
this away from people, you'll probably get some pushback with people
complaining about it slowing them down/taking too long etc

So with that said, I don't think your expectations are unreasonable, but if
this "wild-west" culture is ingrained it is going to be hard to introduce it.

My advice:

\- get explicit "firepower" from as senior person as you can find. Make the
request to do these things come from that senior person, not you. If it is you
boss's boss's boss's boss is telling your team to do it, that carries greater
weight than "the new guy" (no offense) and complaints about going slow or
whatever are then kinda moot since your boss's boss's boss's boss knows the
repercussions and wants it done like that regardless.

\- couch these things as a developer aid. E.g. proper unit testing can help to
prevent embarrassing mistakes or make "risky" changes less stressful, CI and
repeatable builds means that the boring toil of cutting the release is removed
etc. Reviews are a harder sell as most people see it as an intrusion/trust-
thing/"we don't trust you not to fuck up without us checking"-thing/etc.

\- try introducing things piecemeal. At one place I worked, we had CI but
failing tests were not a blocker (we had a more of a jokey "hat of shame"
where someone had to wear a top-hat or cowboy hat or something if they broke
the tests that day) - eventually people ran the tests before submission to
avoid the hat of shame and people were proud to say they never had to wear it
over the past 5 sprints etc. At another we did "ad hoc" reviews where senior
devs or TLs would randomly pick some changes from the other devs and review
those after they had been submitted to get some level of oversight - usually
hideous hacks, lip-service unit tests, or spaghetti messes were uncovered
pretty quickly this way, but didn't "slow everyone down".

Slowly as people get used to unit testing and reviews or whatever you can
slowly tighten the screws and introduce more rigor. Hopefully eventually
people will come to appreciate the benefits these things bring.

Good luck.

------
sys_64738
This is the culture. You can't change it so look elsewhere.

------
h91wka
This is not unreasonable at all.

------
code-faster
Your standards make you valuable and you're wasting your potential at
$current_company. Find a new job.

------
morphar
Your perspective is just right in my opinion (and apparently most of the
commenters).

I have worked in several small companies with 1-20 devs and have seen this
again and again. I have been thinking a lot about all this, so in case you're
interested, here's my thoughts on the subject.

For context:

I use git for almost any size projects, unless it's a couple of files, for an
internal non-critical project. I create tests for at least the critical paths
and usually benchmarks for hot paths. I use docker to separate dev from prod,
while keeping a realistic environment. I use code formatters to avoid spending
brain power, thinking about details that are irrelevant to the solution. I
monitor and log as much as possible from the start.

Early on I was a part of the "code, then deploy" group, thinking that it was
the clearest, easiest path to get as much done as possible. Slowly I have
learned to use version control as a helper while coding, rather than a chore
to be done after changes. E.g. by not being afraid of large re-factoring, when
I see a way to clean up code or as an easy way to just try something out as it
can easily be discarded again. It has also put my brain into a "segment
changes into similar things" or maybe rather "do one thing, then another",
instead of changing 7 things at once. This is not always true of course, but I
try as it makes it easier to keep track of changes.

The same thing with separation of dev and prod (and test, etc.) - it makes it
safer, simpler and easier to try things out, when you aren't afraid of
breaking things.

On top of what you have mentioned, I've also always been the ops. guy, which
has taught me to monitor and log as much as possible, then remove unnecessary
monitoring or logging, when it becomes obvious noise. It also helps you
understand WHY it's important to have working code in production ;-)

What I have experienced:

ALL of the above have ALWAYS been seen as "extra" from the business side and
usually from other devs as well. It's hard to make (some) people understand
the value of checking for correctness now, is better than having to find bugs
and fix them 3 months from now (after they've usually caused data loss or
corruption).

It's even harder to argue for the value of changing existing code AND write
tests for it. It can easily seem like so much extra time in which nothing new
is being produced.

I think the issue can be summed up in just a few points:

We as developers can be very averse to changes in our daily routine and/or how
we do our job. Also: to get any size team to be effective, everybody has to be
on board with 1 way of doing things.

Both dev and biz needs to understand and trust, that what seems to be slow
progress, compared to "code, then deploy", is actually a streamlined process
that makes development safer, faster and less buggy (and more fun) in the
larger perspective.

Possible solutions:

It all becomes a cost / benefit analysis for biz and/or a question of getting
devs to see the benefit in their daily work. Biz can usually understands the
reasoning behind spending more time now to save even more down the road and
avoid bugs in productions as that equals happier customers. Even better: tell
biz devs, they'll have a less buggy system to present, when they meet with
potential customers! The most resilient idea I have fought against, is the the
thinking that you can keep adding low quality code to low quality code at the
same pace without creating more/new problems.

I think that the 1 thing that concerns most developers is what held me back
from all of this to begin with: We want coding to be easy and fast. We want
compile times to be as fast as possible, trying code and testing to be snappy.
Everything that is not code should be the absolutely minimal amount possible.
So... If you are used to "code, then deploy", then testing, version control,
code review, CI, CD, etc. can seem like a lot of extra work, that will take
time away from solving a problem in code.

If you can show what each step accomplishes, a lot of developers can see the
reasoning and if asked if they're willing to try, will actually be willing to
try. The next step is to make sure that each step is impossible to avoid. E.g.
Somebody has to be responsible for code review, pushing to production, etc. It
should be impossible to commit directly to master branch or whatever is used
for live. Pull requests should simply not be accepted, until it meets the
requirements agreed upon.

Sometimes a clear path can remove the perception of e.g. creating a pull
request, being a roadblock rather than a safeguard that helps you code faster
and more safely.

------
11235813213455
you're a PHP developer right?

------
logfromblammo
The vast majority of software development work outside of startups and the
FAANGs is cleaning up someone else's garbage, usually without enough budget
allocated to be really thorough about it.

It's a toss-up as to whether your management will be receptive to any plans
for migrating over to industry best-practices or not.

If are an "A" employee, and you can't handle working with "C" employees, do
yourself a favor, and ask to look into the code base at the interview, then
decline if you notice too many bad smells. Otherwise, you will have plenty of
future work teasing things out of the big ball of mud, fixing them, and then
throwing them back into the blob.

Half of all code-writers are worse than the median. And the median coder will
happily copy-paste the first code that works into six different places, rather
than spare a thought for future maintainability. Then they move on, you get
hired, and will have to discover for yourself that the same broken code is in
six-different places, now with subtle differences due to lazy bug-fixes.

Most companies can't compete with FAANGs on salary and benefits, and can't
compete with startups on coolness factor. There will be some cargo-culting.
Your co-workers will be less skilled than you, but will also have more
seniority. You may, in fact, be able to do all their jobs by yourself, in less
time. Resist this temptation.

How does this sound? Do your own job the first 2 hours or less of every
workday, and then slack off while looking busy for six. Repeat until
retirement. Mediocre companies won't reward you for being a better developer.
They just don't know how to measure it. And they don't have former developers
with still-current skills in management. The way to translate your former
expectations over to a different kind of company is to look for a CTO that
comes from a similar background as you, and shares those expectations. Other
companies don't even know what good code looks like, or how much it costs--
even in 2020, after 40 years of software gradually worming its way into every
other kind of business. They're probably still using the Excel spreadsheet
created by the co-founder in 1992, with all the VBA macros in it, and source
control faked by making copies of it with different dates in the file name. It
works, so why not?

If those software best-practice process requirements are not enforced from the
highest levels, all those sloppy, below-median coders that get hired will drag
the company standard down to what they can handle, or, even worse, turn the
practices into pointless cargo-culting. Those code reviews could be overly
focused on tabs vs spaces, or ensuring that names are in camelCase rather than
snake_case, and putting try-catch blocks around code that does not throw
exceptions (to name some examples that may or may not be actual anecdotes from
my personal experience).

------
mikekchar
There are definitely small and medium sized companies that follow the
principles you describe. However, there are lots that do not. Trying to
transition a company from "do not" to "do" is quite difficult.

Whenever I hear stories like this, I try to ask the person to imagine how the
relatively good practices were born in the better company. The pressures are
similar. The people are similar. There are two really big differences: the
current situation of the organisation and the approach you take to move toward
a better way of working.

One of the easiest ways to change culture is if everybody in the culture is
unhappy. Revolution is just a suggestion away. When you look at things like
the first XP project (whether you believe it was a success or not), it's well
documented that they were able to use XP because they were just so sick of the
thing they were doing previously.

Often this is _not_ the case, though. Some people _like_ what they are doing
now, or _doubt_ that another way will be substantially better. In this
circumstance, I like to try to do something I call "aligning vectors" (which
I'm pretty sure I stole from something that James Coplien wrote, so if so, I
apologise :-) ).

Software is a team sport. When you think you have the correct way of doing
something, it is tempting to go and do it. But if everybody goes off in
different directions, following the ideas that they think are right, the
result is that the team as a whole will certainly fail. Perhaps it won't be
_your_ fault (you walked in the right direction after all), but it hardly
matters.

So what you need to do is to convince everyone to walk in the same direction.
At first, it doesn't matter which direction you go. It is completely fine for
_everyone_ to walk in the wrong direction as long as you can change direction
later. It is much easier to change everyone's direction after they are all
going in the same direction to begin with.

This means that your first task is to align _yourself_ with the majority -
even if you disagree with it. Remember, at first you just need to get everyone
walking in the same direction. That means that _you_ need to walk in the same
direction as the majority.

Next, you need to look at what other people are doing differently. If you
think one person is doing something better than the others, try to align one
of the others towards that person. This is where you need to be a bit clever,
because not all people are equally easy to align.

In any group, there are early adopters, middle adopters and late adopters.
Early adopters will try anything for giggles. Middle adopters need to have
some kind of evidence that the thing is better for them to try it. Late
adopters will not try it until the vast majority of people are already doing
it. So your task is to find an early adopter and get them to try the better
thing that someone else is doing.

Now here's the most important thing. You need to make sure that they are
successful. You need to help that person and do everything in your power to
see that they succeed. If they fail, it's best to say, "Oh, that was my fault
(for whatever reason)", so that they feel OK about failing and will feel happy
to try again with something else. If they succeed, you have to say "Oh, that's
amazing! You are great!" so that they feel happy they tried something new.

Then you need to advertise the success. Once the middle adopters see the
success, they will want to get a piece of the action. Encourage them gently
and hopefully you will get one to bite. If you make them successful and make
them look really good, then others will want to try.

Eventually you will have only the late adopters. The thing about late adopters
is that they are usually _very_ socially sensitive. They will be _very_
uncomfortable with everyone else doing something other than what they are
doing. They may complain. They may get angry (even at you). Just stay calm and
suggest, "Why don't you give it a try? If it doesn't work, we'll learn
something that everyone can benefit from." Usually they will, but if they
don't, it is totally safe to let them do their own thing for a while.

Keep doing this (it takes a long time!) until everyone is going in the same
direction (with the exception of 1 or maybe 2 late adopters). If you do a good
job, everyone will trust you and will be very eager for suggestions about what
to do next (because you have a history of helping them be successful). It is
at this point you can introduce something new: "I don't know if this will work
for this team, but in my last job we did X and it seemed to work really well".

The more success you have and the happier the early and mid adopters are, the
more pressure the late adopters will put on themselves. They hate this kind of
thing. They will either decide to join you, or they will quit. I've never seen
another outcome (and it breaks my heart when they quit).

Anyway, I typed too much. YMMV :-)

------
jayfrasergames
Looking through the comments, I see most people saying these are reasonable
standards, so I'll do what I can to give some contrarian two cents.

The standards you list are: * Code review * Test coverage * Meetings over
architectural decisions, needs for approval for taking shortcuts

The things you've listed have costs and benefits. The benefits are primarily
communication between members of a team, and ability to rely on correctness of
code from other members of your team. The costs are time investment. Reviewing
code takes time, writing and maintaining useful tests takes time, and meetings
for day to day decision making take time. In order for these practices to make
sense, the time that they take to implement has to be made up for by the
efficiency gained by a team using the practices. To take a trivial example, a
solo developer working on code would absolutely be wasting their time to
implement all of these things.

These practices also have costs in terms of iteration time on coding
decisions. You are much more free to experiment and change around code when
you don't have to do these other tasks alongside. This is especially relevant
when you are creating a solution to a problem you do not understand well - in
that situation initial solutions tend to get thrown away anyway, so there is
no point making them to a vigorous standard at extra time cost. Instead, it is
better to explore for a solution which works, and then once a good solution is
found invest the time in making it robust later.

With that said, you yourself said that you see how slow dev is, and you know
how fast it can be with this discipline, which makes it a bit pointless
answering your post because you are already basically saying that the way you
want to develop code is superior in the post itself. Anyway, supposing that is
true, if you prove to the people you work with that you can improve efficiency
with the practices you are talking about, and they subsequently ignore that
input, then you have definitive prove that the people you are working with are
not acting pragmatically.

Fundamentally - when making software the actual task you have to solve is
creating software which solves a given task to a given standard of robustness
in as short a time as possible. The practices you have listed are strategies
for team coordination, and they do not apply to all team sizes. I've read and
seen enough of people online who think that every company/team should model
themselves on bigger teams - e.g. Facebook/Google/Twitter/whatever, and this
leads to a lot of false beliefs in software development. These days people do
crazy things all the time because they have in mind some dogmatic notion of
"the right way to develop software". In order to be a pragmatic, effective
software developer you need to rid yourself of any dogma you may follow, and
phrase your questions in terms of what the problems are and how they are being
solved. In this case, the question shouldn't be "does my team do x, y or z?",
it should be, "is my team utilising its resources to deliver product x to
robustness standard y within time frame z?" and if not, you need to know "will
practice x help?" and if so how will it help.

------
axegon_
It kind of depends on the company and the projects at hand. I've been in a
similar situation and still am now to a fair degree. Back when we started the
projects there were no guidelines or clear rules and definition set: "There
are X developers, this is what needs to be in production in a month". Hardly
any specification just a vague explanation of what was needed. Which might
have been fine, but half of those developers were as bad as they could get.
And even spending 7 days a week at the office was not enough. I mean no one
could realistically finish what they were doing and then go back to cleaning
after the others. But, 30 days later we were in production(till this day, I
have no idea how).

The biggest problem was that most of the bad developers were located in a
country, where once you are past your test period, and you are at work at 8,
no one can touch you. Meaning that for years, they were doing every anti-
pattern known in the books, and someone cleaning up after them(in most cases
me). And in those conditions you are left with no choice but to... Cut
corners... Eventually we managed to pressure all of them to quit. Keep in
mind, there were entire releases where I've personally had to re-do everything
they had done for that release because it would take less time than it would
take me to tell them what they have done wrong or why. And they were perfectly
happy with that. All while every deadline was approaching fast. Now with them
gone, things are improving, though we still spend countless amounts of time to
clear the roads from what they left behind while still having to build on top.
Which, sadly, is a slow and painful process.

My advise - do the best you can do to your ability, even if it means cutting
corners for the time being. Once the water has set, things will start going
back to normal(but that could take a lot of time). This has to do with the
lead developer(which we didn't even have at the start, and one was appointed
much later). Eventually he quit so... I was next in line for better or
worse...

So a 3 things you need to figure out:

1\. Lead developer - are they pedantic, strict and do they go over stuff when
they have free time and fix/optimize things? If they do re-factor or even
rebuild entire chunks of the application with the intention to improve it,
then sit back and relax. Things will eventually start falling into place(see
my following points). Go through something big in the project they have
developed on their own with sufficient amount of time at hand? Is it clean,
well structured, documented and organized or is it just "working". Do they
write documentation when they can or do they just kick the can down the
road(again, stressing on "sufficient time")? If it is effectively good code,
you are on the right path. Granted that the rest of the team has the will to
learn and improve. Tl;dr - follow the leader, something which has been
instrumental for many of the developers I've worked with. Eventually they will
start mimicking the leader's behavior. Your best course of action is to give
him/her enough space to be able to clear things out - you know - flatten the
curve.

2\. Tests, while good, are not always a clear indicator. Sometimes people take
tests as ground truth and as long as a test passes, they will call it a day.
In addition, some systems are way too complex for automated tests. I have such
an example, I've worked out the math: you need a 124! (yes, factorial) to
cover all possible scenarios. And counting... Good luck with that. So yes, no
tests, just making sure that there's a way to restore things if something goes
wrong.

3\. Company infrastructure - some companies are incredibly strict and
conservative, meaning that developers end up having to spend ridiculous
amounts of time trying to get around firewalls, rules and regulations. Which,
as you can imagine, takes a lot of time and a lot of effort to break out of.
But with the adequate amount of will and time that's not impossible.

------
mixon
I don't think your standards are unreasonable but maybe they are a little too
high.

Tests, CI that runs the tests and does not allow release to production if any
of the tests is broken, and automated deployment are probably a must.

Code reviews are probably not.

Not sure about infrastructure managed in code.

------
mattmanser
To counter the flood of 'you sound reasonable', I think you are probably being
unreasonable.

The hint is "spaghetti code".

What might have happened is you started slagging off everyone's code as soon
as you've come in and now you're plucking at straws to justify it as you're
getting ostracized.

Also, objectively speaking, how can writing MORE code and spending MORE time
talking to people be faster? Your argument makes no sense. Tests and reviews
are a massive drag on development, also more code means more bugs. That we
know.

It would take years to get full test coverage and somehow you think that makes
everyone inherently faster?

Also, ask yourself this, how much money have they lost so far by doing this?
Is it perchance $0? Zero downtime? As you've not listed a single actual COST
of what they're doing.

While direct to prod/connect to prod db is nuts and not normal, you also
haven't given the context of who did that and why they did that. Is there
really no staging server? No Dev branch?

~~~
anthony_r
I take it you've never worked in that type of an environment, with code review
and (good, not necessarily perfect) test coverage. I am working in an
environment like that and I regularly push 20-40 changes per week. There's no
problem with speed. Furthermore, had there not been tests (and not just unit
tests; the important stuff is large scale performance tests and output
differs) I would never be able to push code out so quickly.

~~~
mattmanser
I can regularly push 20-40 changes per week, with or without tests.

What's special about that?

How can writing MORE code be faster? Be honest with yourself, you know it's
slower, it's hard to get right, and it's easy for many programmers to end up
writing really bad tests that hinder rather than help.

Certain orgs might be able to pull it off, but generally speaking it's cargo
culting.

~~~
UK-Al05
It works because tests provide you with incredibly fast feedback if your
change works or not.

Then you can confidently and automatically deploy to prod straight away
without much manual checking.

