Like many here, I have successfully made a career transition into web development.
Whilst I have made a post similar to this before when I first got my main developer job a few years back, I have since rapidly progressed to a “Senior” level, and hope what I have shared helps anyone reading this. I will try my best to share my tips with a fresh coat of paint - putting Senior in quotation marks is the first thing for a reason.
First and foremost, learning to code is never a sprint, it’s a long run marathon.
And time and time again you will hit stumble blocks, you will fall off the course. Even this week I was working on a Laravel heavy project, and the sheer amount of roadblocks I had was a lot. Feeling like you won’t progress anywhere is very normal regardless of experience level. Therefore, always be prepared for the constant criticism (mainly self-criticism) in the workplace, it’s tough but every challenge does make you a better developer and this career has one of the biggest payoffs when you achieve milestones
One big thing I used to do when I started - when approached with a problem which I couldn’t figure out the third time (that’s right the third time - I purposely did not say first) I really started to be harsh on myself. I would say this is a very normal feeling that is known as imposter syndrome especially when they get their first role in tech. The first time you should expect to hit a stumbling part, so I specified third time to symbolise that more challenging work situations where it would be the norm to constantly get stuck on complex business needs.
If I had to choose which tip is the most important, I would say look after your mental health whilst you learn, outside a job or inside a job.
This discipline in itself is constantly mentally draining. All careers have some sort of drain whether it be emotionally, physically or mentally. Without a doubt, tech is primary a drain mentally.
Therefore as a learner, your efficacy in learning will be largely limited unless you look after your own wellbeing. The feeling of “flow” during a productive work session can only happen in a more consistent basis when sleep is of higher quality. And information simply won’t be absorbed if a learner lacks sleep, or at least, not to an efficient level.
Always work smart - not hard. Looking back when I first learnt to code, i wasted time in the “abstract” a bit too much like many newcomers. Learning definitions to an absolute T when in reality, being too academic is actually disliked in most workplaces and what is actually needed is minimal.
You’ll find interviews ask about definitions of map, filter, ES6 and so on. These academic HR questions are foolish and silly to test someone. Practical tests I fully agree with, especially when they reflect an employer’s actual coding needs , this helps both candidate and employer see if they are a good match. Repeating definitions as verbatim however? Not reflective of the job in itself.
In a real situation, having an intuitive feeling of how it works as a starting point is enough because you would obviously just google a definitition again when needed and thats fine. Having a good memory doesn’t mean one would understand how something works.
My own waste of time of digging into too many details was largely due to a lack of direction in how to translate ideas to practical knowledge. That is why I found FreeCodecamp a life changer.
If I could go back and change things? I wouldn’t bother wasting time learning things to an unnecessary detailed technical level. I’m sure this point is more controversial but ultimately, what you actually CAN create in the practical sense is what matters the most in a job situation.
Personally there have been countless times where the “best case scenario” simply cannot be done due to technical debt, deadlines and long term sustainability.
Whilst this does depend on where you work end of the day, every position I’ve had (five so far) including when I was working as a contractor, the ultimate goal was “as long as it works and is maintainable for the future” was what really mattered. This goes onto my second point of advice - think in terms of business.
Is it worth spending 8hours on making the “perfect” solution in terms of speed at the cost of, well, time and money? What else matters is making code that is easy to understand by others.
What if one spends an additional 2 days to make the “perfect” solution to a feature only to see that same feature is scrapped 2 months later?
This is ridiculously important and a constant frustration I see, partly perhaps due to the “INTP” culture of most developers, where technicalities and semantics are focused on too much without seeing the bigger picture.
Relying too much on semantics is not going to gell well in a team. Arguing over the smallest of details does not make the business money, nor does it create good rapport with a team.
On countless occasions, I have found that a group discussion on building solutions that can balance usability, workload and sustainability is a constant juggle of priorities and understanding of what the team actually needs.
Realistically, no team will ever make the “perfect” solution each time in terms of performance. Of course this is ultimately determined by the nature of the job you have, but the majority of clients I have worked with which involve business websites used to advertise for services and such, they simply won’t care how much technalities you talk about. Why would they care about minutia they do not understand? They care about how much money your solution can make them.
In thinking of terms of business, the key idea is to “sell” the benefits of the solution you or your team may be creating. I have seen time and time again the inability to communicate exactly what is being made for the client. What happens instead is a technical ramble on things which confuse and waste time even if it’s “technically correct”.
Unfortunately, if you do work a job in tech, ultimately there will even be some “politics” to handle (like all jobs) and henceforth, solutions will not always have the chance to be made perfect. From the nicer perspective, they don’t have to be in the first place either.
Business skills are also important for your own development and opportunities. By taking the initiative to ask and get involved in new technologies and projects with a good level of evidence and explaining why it would help where I worked, I have had many new doors open.
I started started my most recent role on frontend, but transitioned to backend by my own initiative. This discipline is as we know, is a very open field. I would say it’s a massive red flag if where you work doesn’t allow you to flourish and work on your own development goals.
Whilst a business may need things to get done ASAP for their own profit, at the end of the day, a “win win situation” should be the culture of a good work environment, where in the long run, developers giving the chance to do bits outside of their main role does wonders. This ultimately helps the business too because of more long term skills with more staff having those needed skills.
E.g. if a team only has one person who can manage server set ups, what happens in an emergency when that developer is on annual leave?
If a business is way too short sighted and cutting too many corners, then I would definitely say make a exit strategy. Learn what you can but apply for places where you are allowed to flourish. Everything in work involves risk, the key is to learn and adapt to those and ask yourself what level of risk you are willing to put up with. If it’s too much and the stresses are damaging your health? Start your exit strategy
From all 5 places I have worked thus far, there was only one extremely toxic and unrealistic in what it expected from employees. It was a constant strange vibe of being expected to work and do everything but paid the least possible in the area, despite them having some big clients so it was evident they could pay more if they wanted to.
There was another developer who had more experience than me who was even more shocked and decided to leave. The company would have “deadlines” but never actually communicate clearly what is needed by when. Even as a junior, there never was any development plans in any vague sense either. Immediately you were expected to hit the ground running and make the work you do profitable, but most businesses have the common sense to know that the first 6 months or so a new junior is a long term investment. Not this place where I worked, leaving only 5 months in was the best career decision I made. I then got my current role which I’ve stayed in for nearly 3 years and haven’t looked back since. Whilst I planned to leave after 2 years, there is still a constant stream of new skills to pick up and having good work relationships really does matter, so I am in my current role for the long term.
By being able to convince my boss why I should get involved in backend projects, I was able to pick up laravel on the job. This was one of the greatest breakthroughs career wise, because becoming a full stack developer is extremely satisfying, as I was able to learn docker and nginx too.
I might be the odd one out here, but I started coding without much passion which is rare perhaps. As time went on, years of doing it as of now is what made me love the job. The stage which made me realise I love what I do is when I was able to do full stack.
The concept of all the pieces falling together and having some understanding (remember, perfectionism is not a good plan of action) is very enjoyable, a feeling of flow and security that you can help your team and understand how to improve things for the long term. And that’s being the developer - being content to be able to continuously work on that long run marathon and have some satisfaction from it.
Finally, on the business side of things, you deserve to be paid well. One time I thought I was “overpaid” but actually, I am not. What I mean is, for my years of experience, I am probably paid more than most other web developers in my area who have the same experience. However, thanks to negotiation and the ability to have an open conversation with confidence, believe me, you can fast track your career much faster than the average pace. This doesn’t come naturally to many in the field I would argue but at the same time, I definitely believe everyone has the ability to help themselves in confidence. The saying “the more you put in, the more you get out” is … partially true in coding.
For example, you could be the “loyal” employee who works 8hours paid, 2 hours unpaid but you would be underpaid compared to someone who has negotiated what they are worth and does a consistent 8hr workday. I have seen this happen way too many times and it is unfortunate. In theory the person working the hardest should be rewarded the most but the reality of the workplace is that’s not it at all. Therefore, this goes back to my first point - look after your mental health first and foremost.
When starting a job, you set the standard for the rest of what is expected of you. If you immediately work unpaid overtime for hours, then suddenly decide to stop, you will be shooting yourself in the foot.
Technically, you are more helpful to the business but they may not recognise all that extra effort. Than as soon as you work normal hours, they may still expect the same productivity you had before working unpaid. This does not make any sense at all but a lack of self awareness is quite common unfortunately in the workplace for the employer side of things. I have seen too many good willed developers exploited for their skills. Don’t be another.
The final point I’d like to say is the most important is this - never work with ego. Be detached. The absolute worst thing a team can have is a “know it all”. I would say there are many times I have asked a “junior” to help me double check my own understandijg of things.
Humans tend to love their own sense of status, but what I really appreciate about where I work at the moment, is “senior” and titles are meaningless. A true developer is an eternal student, and no matter how many years of experience you have, do not boast or take on more than you can chew at work because it WILL be noticed and frowned upon. If you need help? Ask. Do you feel your solution isn’t the best? Seek feedback. Do you think you made a big mistake on a production site? Don’t hide and pretend it wasn’t you, put your hands up and let others know. Sooner or later the truth always comes out
So yes - I hope the “flavour” of this post is unique in its own way, since I really want to help others in the community now. I have taken a long break from being active on this forum but very soon I will be more active trying to help out.
Freecodecamp was life changing and thanks to this career, I have now had the opportunity to work remotely anywhere I want on a good wage, hours and more than enough time to go to the gym most days etc. This is the beauty of tech, there are no superficial barriers to entry. Your own graft speaks for itself as does your individuality.
If my post helps at least one person, then spending hours writing it will definitely have been worth it!