I officially have three years of experience and a mid-level job title. My best advice has changed significantly since I wrote 12 Things I learned D...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Thank you for sharing, Abbey
I am a self-taught programmer, and like many others in our field, I experience imposter syndrome from time to time. Learning programming concepts on my own and not having a degree in CS are constant concerns that come to mind. Starting to learn programming at 27, in addition to the aforementioned points, made me even more insecure.
By sharing all of this, I want to highlight another challenge that many juniors may encounter: shifting focus.
Now that I've overcome this mindset and found a bit of comfort and confidence in my path, I can see more clearly that I've wasted many days of my working hours being sad about the role I have and pondering a switch from front-end to back-end.
The lesson I've learned from this phase of my life is that by giving myself enough time and staying focused on my path, I can overcome my insecurities and find joy in my role again.
My message to new joiners: find what you love, stay focused, be patient.
Imposter syndrome is tough. ๐ This is another area where community is very important. I also don't have a CS degree and started learning to program at 28. I have learned that knowing about both front-end and back-end is a boon even if I'm in a role currently focused on front-end. A lot of this perspective came from talking to senior developers when I was a junior.
Yes, the community really helps. It's definitely important to learn both sides as a software engineer, in my opinion, and creating a T-shaped skillset would really help, sometimes being crucial. However, shifting career paths and putting much effort into a secondary field are what hold some individuals back, as I have experienced myself.
The you have links to community a beginner can join?
Thanks.
Sorry, unfortunately I haven't been really active in an online community untill now.
In the past, I relied on my circle of programmer friends who provided invaluable support. Over time, this circle grew, especially as I worked in various companies.
However platforms like here ( dev.to ) and freeCodeCamp forum can really help.
Also ADPList offers fantastic opportunities for mentorship and support.
I'm also a self-taught developer who begun at the age of 28. But I only learned front-end first because I was always told that as a self-taught developer, it was better to specialize first in something then doing the T-shaped skillset same as the software engineers.
And actually, it was the best advise I could get.
I specialized in vanilla CSS, then went deep in vanilla JS to make a deep dive in React. And my knowledge today, 5 years later, is good enough for having me teaching the software engineers how to use correctly React, setting the good practices and the base front-end technologies to use for the whole company and I was just offered to become the tech lead.
And this company is also giving my time during my job to learn back-end and devOps. I'm glad I focused on something to be very good at it instead of having tried different technologies, I wouldn't be where I am at today.
So my advice would be to maybe find what you like best front-end or back-end and focus on one of them first. Be (very) good on what you do and the sky will be the limit
And if that works for you, great! I and many other people have made a career out of being a wildcard person/generalist/full-stack developer. I've always seen "T-shaped experience" used to remind career changers that their previous career taught them skills that apply to tech. Using it to describe the types of tools you know well is new to me.
Being very good at a few things came from solving whatever problems were thrown at me and going deep on what I was interested in. I respect the people who can be consistent and focused on one thing, but that's never been me. Some people learn best by focusing on a few tools while building a project. Others can sustain focusing on one tool, language, or type of problem for a while. Neither is better than the other or reserved for people with CS degrees. In fact, the tip about being able to turn ticket requirements is aimed at new CS grads as well as self-taught developers stuck in tutorial hell. ๐
The important part is finding what type of learning works for you and what you need to sustain continuous building and learning. It's easy to beat ourselves up for wasting time or not making linear progress, but life happens and we still probably got useful experience (or rest) out of the detour.
Many of the best developers I know and a whole lot of the best developers in history didn't have a CS degree. I hate to see anyone feeling insecure or sad about common developer experiences. That's why I keep writing these kinds of posts and try to save space for people to share like @borzoomv has.
People have been assuming this blog is only for people with less experience than me. However, I've noticed a pattern in senior developers limiting themselves. Whether it's from a lack of community/perspective or a lack of confidence or both, it's easy to focus on the things we still struggle with, what we can't do yet, and where we are compared to others. It's a double-edged sword that we as developers have to know what we don't know. I'm proud of anyone who regularly practices the amount of learning, trying new things, and creativity it takes to build things with code. ๐
Thank you, i'll definetely check these sites.
I appreciate.
Thank you, i'll definetely check these sites.
I appreciate.
Hi Borzoo, I agree with your thoughts. even I started programming when I didn't have a CS degree. it made me feel like doing coding without any vision. I worked on myself and read a lot of articles. I finally, enrolled for a CS degree while working in an IT company. I got my CS degree last year and I still feel like I should have enrolled in the past for regular instead of distance education.
I've left that feeling a way behind now, and now I have been working in IT for 8 years. I think It's not important for me now. Rather what's important for me is improving my current tech stack and learning.
I am Number 6. Every time we type anything we add to the risk of fragility. Keep it simple. Reuse tested code. It's a winner for me.
Who is number 6? You are, number 1
Hi Abbey, An absolutely brilliant article. It highlights everything I have been saying for years.
I particularly like point 11, as I started in software development many, many years ago by teaching myself, because I discovered a passion. I went on to study a CS degree, which was the main way in to the industry in those days.
For more than 20 years I have been a web technology specialist and still love my job.
Number 2 is so important, "I don't know" is perfectly fine especially if you can add "but I can find out".
If you experience imposter syndrome, learn this: everyone is winging it ๐.
After working for 6 years on a single framework I can tell you that it still feels like I know nothing about it, neither do I even try anymore, you've got Google, you've got documentation (albeit bad at times), don't fear telling your colleagues that you don't know - do tell them that you are going to find out.
As a senior level with decades of experience, I can confirm this is all excellent advice! At this stage in my career I am mentoring and leading mid-levels. Reading this was a great refresher for me on the mindset and learning opportunities for them.
Hello world!
Hi Abbey. Thanks for sharing your advice and experience. I am still new to tech as a whole. I am in my 30s and my first degree is in Biology ๐ . I discovered I loved computers but never had the chance to learn them back in high school plus I used to feel like it was a very complex field and too complicated for me to learn.
I am currently learning Full-Stack Web Development and am going to use your advice even as I am learning right now.
Once again thanks for sharing.
I have been a dev for over 15 years and these are all great lessons to learn. #4 I particular really hit home to me.
For the vast majority of my career, people have been astonished that they can describe a problem to me and I can usually tell them where the problem is in my first guess. That's because I always make sure to have a deep understanding of how the entire system works.
And now I will share a tip from an architect that goes along with your first tip (sorta)... Influence is the name of the game. While level doesn't matter, what you do and how you show it matters a lot. If you are constantly proving that you know what you are talking about and build trust within your community, it is a lot easier to influence others to your way of thinking.
If you can't build that good will and have people respect your opinions, you are never going to get a promotion. As an example, I have been with the same company for most of my career. I was hired at the lowest level of dev and I now have coworkers who have been at the company longer, were 1 to 2 levels higher than me when I started, and now I am higher than them.
Your point 10 is very spot on in this respect. Having a support system that can guide you and push you helps a lot. It helps point out your weaknesses and how to address them. I would encourage everyone (especially jr devs) to find that experienced person (whether internal at your job or external like meet ups) to be a friend and mentor.
I am glad that proving you are technically competent has been enough at your company to garner influence and promotions.
For others, I recommend keeping a brag doc, so you know what to bring up at performance review time. For those who struggle with self-promotion, I recommend practicing stating your achievements, even if you have to do it so factually even your own brain can't argue. If you find there is no established goal post for promotion at your company or the goal post for your promotion moves as soon as you get near it, I recommend moving on to get the compensation you deserve.
I am also going to push back on
Many of us get the challenge, pushing, and identifying weaknesses enough outside of our support network. It is totally fine to rely on your support network for only support. Mine has been instrumental in identifying which criticism is worth listening to and what kind of professional development environments will actually further my career/be healthy for me.
As a mid-level developer myself, I found these 12 tips incredibly valuable. It's always refreshing to hear advice from someone who's been through the trenches and knows what they're talking about. I especially appreciated tips 5 and 9 โ they were exactly what I needed to hear right now. Keep up the great work, and please keep sharing your knowledge with us!
Many thanks for the great tips. Especially tip seven, as a beginner, I only recently realized how much time it takes to understand other people's code when you've spent most of your time learning to write code from scratch.
This is a well-written post, Abbey. I am self-taught and have experienced many of the points mentioned. I have to stay focused. Thanks for the insightful tips.
This is great advice! It's honest, down-to-earth, and not just all about adapting to AI! It addresses real things that we forget about as developers! This was a really great read. Thank you!
Number 11. is very important!
There are so many areas in programming and you need to pick one :)
Thanks for writing this post.
You've given some great insight and actionable tips.
This is all exceptional insight ๐ฅ๐ฅ๐ฅ๐ฅ
Wonderful blog
Great Insights right there. Sincerely appreciate this.
Great tips
I regret that I have but one clap to offer.
Your last sentence was the most important one in this post. Just be grateful, be kind.
This is such a good post. I couldnโt agree more. ๐
Thank you for sharing
As a Mid developer, I agree with everything you wrote. Thanks for sharing
Really great article. Something that helped me was that I started reading the entire documentation. I've had a bad habit of just skimming or reading the relevant parts , but reading the whole thing has been super helpful. I don't always retain or understand everything, but it has introduced many new concepts to me and saved me a lot of time overall.
I polled two other developers and @fimion does indeed read all the documentation. He's also "that one friend who's really into CSS," so clearly smart people do it.
To be clear here, because I wasn't earlier, I do tend to read the whole documentation... For fun. If I'm in a hurry, definitely skim to the right bit.
This is very true, but also a bit simple. I think most people understand this in principle, but struggle to implement it in practice.
Knowing how to try something out is a skill of its own, and one that doesn't get all that much attention. But in my experience, and this is also what I've heard and read from others, the really productive devs tend to also be the "Good question, let's try it" types.
There's also a big overlap with setting code up to run often instead of writing big chunks of code.
Excellent article! This is fantastic advice for any junior programmer who wants to start thinking (and working) like an real engineer. I just wish I'd read this when I started out! I'm going to be bookmarking this for future mentees.
First DON'T tell people you are "self-taught". Literally EVERY SENIOR ENGINEER by then is "self taught". IF you went to college - great - you learned HOW to learn (hopefully) - from now on its ALL up to YOU to realize YOU need to find the new things you need to learn and learn them and apply them.
Second TRY HARD EVERY DAY to be humble! I can't over preach this. You will get better and pretty soon there is a WIERD tipping point where you have to put your ego in check with everyone else around you because now YOU are the senior. Getting a "big head" only hurts everyone. HUMBLE YOURSELF!
Last, in general don't be afraid to MOVE ON! The ONLY way to bump your pay significantly is CHANGE JOBS! DON'T stay somewhere a decade or more unless you are POSITIVE you have a great deal going there. Those cases are RARE!
You ALWAYS need to be challenged, improve yourself, be a GREAT example to the juniors and mid levels and people in general. NORMALLY.... to get all those things requires making a dramatic change.
Good luck!
I can see a lot of people saying they had imposter syndrome been self-taught. I was in the same boat for a few years.
Around 2011/2012 I was in a dead-end job and came across Treehouse online. I bought a MacBook then to learn how to DJ, but thought I had a go at the whole programming thing and creating websites. I started learning on the evening after my day job. I thought I was clever so learning programming would be a walk in the park, I once coded a whole website not looking at the results, finished looking at the browser to check results and it was a black screen (css positioning was the issue), but couldn't figure out why for days. I was so disheartened and nearly didn't programme for weeks. But wasn't going to give up, got back into it and finally got a job.
Over my 10 years, I met all sorts of programmers, mentored some grads and been mentored, and worked for top companies in the UK. I treated imposter syndrome like this, you feel like you are not too good and people are far ahead, right? So what if you spend some time learning to get to their level, at least you are trying and can't do more than trying can you? I started learning more outside of work on evenings and weekends. Also reading more, that I am not on about programming books but the concepts of programming like design principles and that.
Keep working hard and it will all finally click, believe in the process. That is all you can do, protect your mental health.
Thanks for sharing! Very useful tips!
Great post.
Agree with all your points.
Thanks!
Thank you for sharing
Thanks Abbey! After a 'first career' in economics and international development I'm dragging myself up the coding mountain in my fifties. I've learned many of your tips the hard way :)
Do you mean intermediate software developer?
Geesh.. I thought people only makes intermediate softwares.