3 ms·
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
by zests 6y ago
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 6y ago100% 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 6y ago(Did you mean you'd choose company B?)
- Radim 6y agoNo, "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".
- mattalbie 6y agoI don’t even work in software and find this all too familiar. Too many small companies are like this.