- Crumby offices ✅
- Beige walls ✅
- Boring industry ✅
- PHP ✅
- No MacBooks ✅
Wrong, wrong, wrong, wrong and wrong.
Some of the most interesting work you can do as a developer is at "non-tech" companies, in established industries on an older tech stack, perhaps in PHP on industrial estate somewhere. Why? Because those businesses have enough legacy and foundation to generate interesting problems.
So, if the above aren't the signs of a toxic workplace, then what are?
This shows that the company don't realise how hard it is to estimate technical work and has no appreciation of the ways that unforeseen complexity can delay a well run project no matter the quality of the dev team. This doesn't mean that there should be no deadlines, that would be absurd as well, but a business that can't be flexible and accommodate the unforeseen and either move the deadline or descope the work is not a healthy place to be. Often they will move deadlines for finance and marketing but not for technical work, if you see this - run! 🏃♀️
Product people are amazing, and good ones know that dev work is like an iceberg, the bit above the water that you can see (the UI) is likely less than 30% of the work. A bad product person will set features without this in mind and massively over burden a project, or block of work because "it's just clicking a button". Never mind that that button might kick off several parallel jobs, run deployments and spin up scalable infrastructure. If your product people aren't working hand in hand with your technical management and team then when it comes to crunch time it's going to hurt ... you.
Agile is about fast feedback, short blocks of work and getting a rough idea of a teams rate of delivery. Product managers who expect the sprint velocity (delivery rate) to go up each sprint "because you are getting more accustomed to the code base" are really just forcing you to work harder and faster so that they can look good. Some sprints your team might deliver 80 points and other 65, the second sprint isn't a failure, its a reflection that no matter how much Agile coaches try to make dev work like a factory production line, it isn't.
True pair programming, where two devs work on the same feature and deliver it together is great for onboarding, up-skilling and increasing organisational knowhow. It can be slower in the short term but, occasional to regular pairing is a good example of "go slow to go fast" because in the long run the overall level of the team is higher and they can operate quicker. Banning this for short term gain is a sign of misaligned priorities in the company.
This is the ultimate symptom of a broken system and team, I've been here and it’s horrible. Pressure to deliver is so hight that things that sound like they're "not adding customer value" get pushed to the wayside. This is another example of short term gain for masses of long term loss and eventually drowning in tech debt. As a developer it is your responsibility to test what you wrote and know it works, the work isn't done until it's tested.