Related Posts
Additional Posts in Software Engineering
I would like to know the interview process of Hitachi Vantara. The first round of Solutions Architect interview happened yesterday. Can someone provide an insight about number of interviews and how many days does it take to complete the entire process? This was specific to services business line. Appreciate your response Cheers! Hitachi Vantara
Hi All, I recently interviewed at Amazon and Google for software engineer and passed both interviews. I have an offer on the table from Amazon but with Google I am officially in team matching and my recruiter tells me that the queue is pretty backed up now and it can take a long time. My question is should I take the Amazon offer now or decline Amazon and hold out for Google? I have heard that Google has better wlb/benefits. But I'm scared to decline Amazon without a guaranteed job offer.
New to Fishbowl?
unlock all discussions on Fishbowl.
You work at a startup? If so, this is standard procedure 😅
Large company, smaller teams
The harsh truth is that you write code to appease someone who pays you. If their idea of a release doesn’t include time for testing, then testing is not a priority for them.
You can try to speak on it to your superiors by showing how lack of testing is affecting the product. You can pad dev time with extra cushion for testing. You can also leave for greener pastures. However, one thing you can’t do is frame it in a way that’s about writing “perfect” code.
I see it all the time. It never works. An eager dev says that the team should be writing the product in a certain way, because a specific pattern or architecture fits the project. Or perhaps the dev feels that a module needs a rewrite to accommodate changes that weren’t introduced well. The response is always, “How is the change a positive for the customer?”
Make your suggestions about product stability. Don’t be afraid to look for a job elsewhere.
You are not powerless here.
If it needs testing just do it.
If you need to pad estimates for that just do it.
If you want to feign incompetence in planning so you can get the cycles to fix, that is always an option, you are just choosing not to.
I'm not saying you should disobey orders and get court marshalled though, so use common sense.
Discuss the trade offs. If you are a broken record and keep talking about testing that's just not as effective as someone that leads by example and does the actual testing. People don't want nags they want problem solvers.
Sometimes first on the market beats perfect. It's not glamorous. Second place at a race with proper form isn't gold, and some folks want the one that finished first that ran screaming with arms flailing.
I’ve been vocal about how this affects our team as well as our clients, but it seems they are more concerned with essentially making incremental changes on a weekly basis rather than taking some extra days just to get something right. From a technical perspective this drives me insane as this is not the optimal way to solve issues and make improvements in my opinion.
Sounds like you don’t have great deployment processes. Cutting out features and improving later is ok, but not properly testing things can piss users off
Pro
Yes, have been at this situation far more than I like. But this is reality sometimes. A startup I am a fractional cto now is going through the same situation and it is getting worst. The business thinks they are delivering value so often but what they are delivering is broken pieces of value and this has a major impact on their customer outlook. So I am helping them get on track by putting certain processes in place to help the business prioritize using a quandrant approach where the axises are business impact vs development complexity.
So far things seem to be improving.
Any advice on how to cope while you’re in it? This drives me up a wall because we wind up having to fix the very same issues that were introduced due to this broken process
Rising Star
Good enough development is tough to cope with as an engineer. But as the engineer you have power to say what constitutes a working product. One of my tactics is to piggyback tech debt refactors with P1 bug fixes (it has to make sense though). If leadership wants you to ship broken products in the name of speed then abandon ship because broken is never good enough.
Yes and no. I've worked at a place where the vp of product said "just don't test". And effectively tied a teams performance to not testing.
The result was that when this project picked up and became important, two more teams came into it, and it was a ... Really good time for everyone.