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.]

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.

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.

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.

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.

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.

The Joel Test :

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s... *

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?

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.

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.

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.

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

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.

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!

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.

> 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.

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.

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.

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.

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.

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.

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.

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.

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

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.

> ... 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). 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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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!

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."

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.

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.

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 :-)

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.

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.

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.

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.

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...

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.

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.

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.

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

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.

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.

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.

> 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.

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.

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.

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".

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.”

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.

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.

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.

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.

> 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!

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!

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 .

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.

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.

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

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.

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.

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.

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.

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.

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!

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 :(

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.

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.

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.

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.

Welcome to the world of well versus poorly run companies.

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.

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.

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

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.

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

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

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.

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

This is not unreasonable at all.

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

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.

you're a PHP developer right?

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).

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 :-)

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.

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.

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.

These sound like small orgs. In a bigger org, it’s the Wild West, and it demonstrates that the “agreements” and cultural practices can’t be relied upon. The standard is what’s enforced. If people are able to just blithely connect to the prod DB, they will. If you want them to stop, remove this access or put it behind a wall that requires them to declare a reason why they are doing it. If the build doesn’t enforce modularity, devs will violate modularity, either in the interest of expediency or just inadvertently.

The standard is what’s enforced, not what’s written on a Confluence page everyone skims on their first day.

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?