Introduction
Have you ever been excited for a new job and then realised you’d messed up once you joined? Maybe you have, if not, I welcome you to read this to learn how to avoid it. If you have been in those shoes then read along too and share your experience in the comments, I’d love to read them.
Imagine you’ve joined an exciting new organisation as a Senior developer. It’s not your first time in that role but it is your first time in a “fast-paced” environment. Of course this doesn’t mean that you weren’t under pressure in your previous workplaces, it’s just that this term was specifically there in the brief description of the job.
It’s your first day and you are fired up! You are in a new city and in a new job working with a new team. You report early to the new job and are commended for your punctuality and dressing. You are introduced to the various teams and all the bosses seem excited to meet you. You learn that in this new organisation there is a Backend team, a Frontend team, a Quality Assurance team, an Operations team, a User support team and even a Business team. Not at all daunting, despite the fact that you come from a background where most of those roles are amalgamated into one or two roles, at most three.
In no time at all you settle and so begins your first real task. This is where the trouble begins of course.
a. Everything is New
You quickly realise that this is a whole new ball game. Despite your knowledge of the programming language in use, you do not recognise the specific frameworks that they are using. You are accustomed to a number of frameworks that all work in a very specific way. The suite of frameworks used here though is completely new and you are completely taken aback. It takes you a day to set up your development environment but not without having to consult with several people on exactly how to do it, none of whom seem to have time for anything other than their jobs.
b. No Design Documents
Despite the sea of change, you decide not to give up. You didn’t get this far by quitting every time things got hard did you? It’s time to demonstrate your grit. In no time, the Sprint has began and you have exactly two weeks to pick a feature from the backlog, come up with a design, discuss it with the front end person, discuss it with the scrum master, commit to certain deliverables, implement it, write automated tests for it (unit & integration), get your pull request reviewed and merged and then run it through QA and get it to the user support team (UAT).
Say what now? Let me break it down for clarity.
i) Pick a feature — The scrum master will define the list of priority features in the scrum meeting. Your mission, should you choose to accept it, is to pick a feature and get it to UAT in two weeks. Yeah, you have to accept it. Your only real choice is what feature you can choose among the priority features.
ii) Come up with a design — This is simple, you know your way around a codebase right? I mean you have over 5 years of experience. Never mind the fact that you’ve never seen some of those frameworks before. What you don’t even know is that the reason that you’ve never seen those frameworks before is that the Architecture pattern in use is not one you have ever encountered before. In your head, these frameworks are just different implementations of the architecture patterns that you’ve encountered before, all you have to do is figure out how they do the same things that the frameworks you know do.
iii) Discuss it with the front end guy — Step 3 is the easiest. The Front end guy knows that you are the subject expert. All they need from you is the payload structure and the URL to the endpoints. Simple right? At this point you are wondering to yourself. Where do I add this code to implement this feature? Where should I expose my endpoints? What modules will this feature be interacting with? Has this feature already been partially implemented? Is there code that I can reuse or do I have to build everything myself? The front end guy knows none of that. The front end guy knows that you’ve got it all figured out and is expecting a payload structure and URL paths from you, pronto!
iv) Discuss it with the scrum master — The scrum master is also waiting. They expect that after a few hours or a day at the most, you know exactly what to do and are ready to commit to the two week delivery timeline. All they need to know is if you are clear on what you need to do or if you want more tasks. You stare back at them in disbelief wondering what they want you to say.
You just got that job, retreat is unacceptable. Hell you moved to a new city for it. What are you going to do? Run back to your old city and cry that it was all too hard? Hell no! You’ve got this man. You just need to commit to the timeline and show them that you are not afraid to roll up your sleeves. You do it.
v) Implement it — After one and a half weeks of 18 hour days and a 7 day work week you’ve finally come up with something. However, you are already late. For one, your pull request is waiting to be approved after fighting with Jenkins for a solid three days. Jenkins? Why? Well, with different sub-teams within the backend team working on different features, a lot is changing and any time you want to merge into the main development trunk there is either a conflict or some integration tests fail.
When you finally succeed, your pull request is 23 files large and nobody wants to look at it. You are exhausted, under fed and generally extremely frustrated from having to learn and implement so many things in a short time frame. Some of it is guess work (assumptions) but you are already late because neither front end nor QA have seen your work and they also need time to test it.
vi) Code review — Hahaha! Few things in life compare to having your pull request (PR) torn apart when you are already late. One, the reviewers took their time before coming around to review your code — believe me, that is not an anxiety reducing exercise. Two, they debunked your assumptions meaning your design needs to change and there is not enough time to change it and beat the deadline. Three, according to them your tests are not extensive or thorough enough.
This is your first real task at the company. The front end guy is mad at you and so is the scrum master. You had committed to finishing this feature as recently as yesterday and that’s the report that they made to management who then transmitted the information further up the chain. Now, you have to go back to the scrum master and debunk that myth. Worst of all, you don’t even know how to implement the pull request recommendations. Did I mention that you are making the front end guy look bad as well?
vii) Quality assurance — Despite your exhaustion and lack of sleep, you pulled a 36 hour shift and somehow managed to beg enough people to review your pull request quickly and approve to merge. You deploy the development trunk to one of the QA environments. QA is busy testing features that were checked in earlier and that are higher priority. They report in the daily scrum at the end of the sprint that your work was submitted late.
According to management, you failed. There is only success and failure in a fast-paced environment where success means that the feature was successfully deployed to the UAT environment after QA sign off.
In the next sprint, QA finds regressions in your code or find requirements that were implemented in a manner that does not please them. The trouble is that there is ambiguity in the requirements — according to you at least, but to the old hands and the QA, they are black and white and you should automatically have known the “company way” of doing things.
You are panicking now. You had already picked up a new feature for the new sprint but now QA has sent back your work to you and apparently, because of it, you are holding up the release. Since it had been reported that your work would be complete in the previous sprint, management is starting to look bad since that clearly never happened.
To the powers that be that means one of three things, either management is incompetent, management is lying or the developer and/or the scrum master are lying. None of those options is remotely palatable. You now have two features to work on, all of which need to go through potentially 5 steps repetitively (ad nauseum) before you can meet your targets.
viii) User Acceptance Testing — Somehow you pull off a miracle. After half a dozen pull requests and four rounds with QA your work is finally approved for UAT. This part is the least of your worries. You didn’t deliver both features but after the harrowing month you’ve had having your pull requests torn apart and approvals delayed, coupled with system failures in the shape of Jenkins, you’ll take whatever you can get.
The UAT guys start asking questions about the feature you delivered. Trouble is, all you know about the system is what you did. If you cannot answer those questions the UAT team will report failures in your feature. This is the last thing you need after having held up a release. Now you have to pull your attention from the already late feature you are working on to try and figure out the rest of the system before you can answer the UAT guys.
That’s not all. They find an issue that even QA can’t replicate and you have to figure it out. The Devops engineer gives you the AWS/GCP credentials to the UAT environment. There is only one problem. You have never dealt with a cloud environment before. You have extensive experience with Windows and Linux servers but a cloud? You are out of your depth. You don’t have time to learn cloud architecture and tools just to investigate an issue. You are already in such bad graces that you can’t directly reveal that you don’t know this too. Your only recourse, begging a colleague/the Devops engineer to show you the ropes.
You make a request that the design documents be shared with you. What design documents they ask? Architectural diagrams showing the various components of system, how the components interact and why the system works that way (why certain design decisions were made). You are promptly informed that that isn’t available. No one seems to have the time to walk you through part of the system let alone the entire system.
One of them is even nice enough to inform you that you wouldn’t get it anyway since the system is too large to be explained in one session. You wonder how you are supposed to figure out what is done, what is not done, what the system can currently achieve, what code can be reused and what code shouldn’t be touched. You are a senior developer right? Reading code should be your super power! You should have figured this system out the moment you landed.
c. Big ball of mud
It’s been a few months and by now you’ve figured out the architecture pattern behind this great system. You’ve bought courses and books to help you figure out a few of the frameworks but management is seriously displeased with you. You haven’t had one free weekend to yourself in the entire time you’ve been there. You’ve ghosted your friends and relatives. You’ve even uninstalled some social media apps. You have dedicated everything to proving that you belong, that you are indeed a senior developer and not a fraud. Despite all that, the team leader feels that you are lacking in nearly all of the skills needed in contributing effectively in the team. Their point is justified by your slow rate of delivery. Even you feel like a fraud at this point.
Unfortunately the system is not done with you yet. You add something as part of a new feature and the team leader promptly informs you that the functionality is implemented in another part of the system. How would you have known this? Reading the code, you should have done that. Everyone else did it right? Never mind the fact that they found a much smaller code base than you. Regardless, you need to delete your “duplicate code” and adapt the existing code to your feature.
You adapt it and some existing tests fail. At this point you have had it. Everyone, from the scrum master to the powers that be is mad at you for almost always being late and you thought that someone would stick up for you, but no one does. When you try to stick up for yourself to explain why the delays, it only makes you look more incompetent. To make matters worse, when you try to justify why you chose certain engineering approaches rather than others, some of your teammates claim that you are being defensive. You are bleary-eyed, fatigued and sleep derived. No one is sticking up for you, are you just supposed to let your work be discounted every time. To make matters worse, once every three or four sprints, QA gets on your case too.
d. Obsessed with Speed of Delivery
Everything hurts, your back, your eyes, your shoulders. Sometimes you have trouble breathing when you push yourself too hard. The team leader is reporting that though you have improved, your skills are far below expected standards and management is starting to voice their concerns about your work.
The higher it gets, the more I miss the ground…no safety net no, now you are not around. I have to keep walking to keep me from falling down… — Man on a wire, The Script
At the same time, products team is insisting on a higher rate of work and starts to suggest that the entire team is mismanaging time. Threats of firing start looming in the air. You are trying, you are trying. You are trying so hard that you don’t even go to hospital when you are sick. You try to delay it as long as possible — at least till you can get that feature to UAT.
e. We don’t do that here
Finally, one time, you get a feature that actually leverages your strengths. You implement it the way you’ve always done it — in a way that no one ever complains and your submit your pull request. You are happy with yourself. Finally something that didn’t knock the wind out of you and could be delivered on time.
The smile is wiped off your face when the reviewers inform you that in the organisation/company that you are in, that approach is unacceptable, simply because they don’t feel comfortable with it.
You are done. You have nothing more to give. Once again, their recommended approach involves some component of research. The thing with research is that whatever you find out and implement will most likely be sub-optimal since this is the first time you will be doing it. The code reviewers however expect perfection and you have to figure that out too.
Conclusion
I am sure by now you know how this ends. You get laid off because well, you are pulling the team down. Why would you keep pestering your teammates to show you how the system works? Are you a junior developer? Can you not read code? Do you really need that much hand-holding? No. You are simply not Senior developer material, this is their conclusion.
Is this really true? No, not even close. You saw the job, saw the programming language they used and thought that it was a good fit. You never realised that it was possible that they were using an architecture, frameworks and infrastructure that you had never before used. Was this preventable? Yes. If only you had had the sense/predisposition to ask exactly what infrastructure, tools and frameworks they use. This is why it is important for candidates to ask for as many details about the tech stack used at a company, as is reasonably possible before taking on a new job. In this way, both the developer and the company don’t have to go through a harrowing experience.
