Junior Dev Diaries is a career starter blog series for beginner Software Engineers.
It is for developers of any career stage, but will be most helpful for juniors and intermediates. It'll cover a series of topics, from Finding Mentors to Code Reviews and more!
Here are the posts so far!
The career of a software engineer is filled with and perhaps defined by troubleshooting and problem solving. I've picked up more and more tips that work for me when troubleshooting, and in this post I will lay them out for you.
The use of empty strings when used to indicate a null value or lack of value, when the language you're using has a better way to support that will, will lead to bugs and hard to maintain code. With very few exceptions, empty strings should be avoided at all costs.
I've been through the microservices transition in mature startups, large corporate and small businesses. I'm about to embark on another one with another corporate. So, what have I learned? What has worked well?
In recent times, I’ve found myself making similar mistakes in my pull requests. I thought enough was enough and it was time for a solution.
Target State Architecture (TSA) is your architecture, perfected. However, the problem for most companies is that it lives in the back of the mind of the most senior or long-serving engineers. Maybe the CTO knows, but not many others would. Some engineers might know bits of the future and most likely only know bits of the present.
I was recently contacted by a 14 year old student based in the UK, and they had some questions for me about my career and job.
This post is about bad engineers, and one aspect of them in particular - solution favouritism.
Soft Skills makes the term sound secondary or less important. This connotation couldn't be further than the truth.
So you just graduated, you need a job, your friends seemed to have got one, magically, but you’re wondering when it’s your time.
"Should I be a specialist or generalist?" Is a question it think we ask ourselves a lot as software developers.
So you’re just starting out new at a company, and maybe it’s your first software job ever. You’re faced with a new, large, unfamiliar codebase and a bug to fix.
As someone that wants to be more active with speaking, I was wondering how you manage to get speaking gigs?
In this somewhat satirical Junior Dev Diaries post, I want to cover office/tech/workplace jargon and terms.
So you want to get better at a certain language or expand your toolbox, and you’ve heard side it’s good to blog about them or open source the finished(ish) project. Great! But you just don’t know what to work on. Nothing is coming to mind and you’re not really sure where to start!
It's time for another Q&A post. This time I have two interesting questions to answer. What is a senior, and what do I do when I get stuck?
As a Junior Developer, we're often met with many different technologies, all new and foreign to us, and with someone telling us it's the next big thing and we must learn it. I've listened to those people for years now and I've found some patterns for a suitable abstraction of what types of technologies should be in your toolbox. So here there are...
As a software developer, having the ability to learn and adapt is probably the most crucial skill to have. Coming at a problem with no prior knowledge, sitting down and figuring it out is what you're paid to do
Performance reviews a pretty critical in a healthy business, they let you and your manager have a frank conversation on what you are doing well, and what you could be doing better. This is your yearly or half yearly time to get feedback, grow, negotiate position and remuneration.
This series is about how to become a better software engineer, not a better programmer. What’s the differences? Well, coders write code and software engineers build multi-version, multi-person programs. Let’s focus on that multi-person element. Whether you like it or not, software engineering is a team sport.
As a junior or intermediate developer, you might be asked to give an interview. I remember the first time I was asked to interview some candidates, and quite frankly, the idea of that scared the crap out of me. Who was I to determine someone’s ability as a software engineer? Why does my opinion matter? Isn’t this a Seniors job?
As a developer in 2017, it’s important to have some form of online presence. This could be a GitHub (see my recent post), a blog, a vlog or simply just a Twitter account. I think gone are the days of Gamertags and secret online identities, and those acting as their true selves online, giving real, justified opinions, earn more respect. Subsequently having better careers as a result.
For this post, I have a bit of Q & A. These come from blog comments, DMs, tweets and the original survey. I plan to do a few more of these to give back even more, so please send your questions in, however you’d like. I’d recommend avoiding Sky Writing however, the Wellington wind may blow it away before I see it.
As an employer, or even a fellow developer, I want to see your passion for this industry. One of the best ways to do this is to have some of your favourite projects’s code open to view by me and others.
Taking part in code reviews have been one of the most interesting learning experiences in my career. I’ve done some really dumb stuff and I’ve learnt a whole lot with the over 400 reviews I’ve participated in the last 2 years. They can teach you so much about yourself and your code and I’m excited to tell you more about them...
One of the favourite parts of my career so far is getting the chance to speak publicly on topics I’m passionate about. I really enjoy working hard at work, or on side projects and learning lessons, and then being able to share those lessons with other people. It’s well known there are cultural benefits to sharing, teaching and learning, and I think it’s all ours, as humans, obligation to continue that.
Out of that announcement alone, I had several positive conversations with those in the industry. I had two conversations that led to work experience, but I had many more that led to finding some career mentors. I didn’t ask for mentors, I kept it casual, and this, I believe, was the trick to it.
We know as good software engineers that learning, and continuously upskilling is important to our careers. In fact, it’s important to any career. But what the hell do we focus on? There’s a seemingly infinite amount of directions and paths to explore and content to learn.
Hi, I’m Sam. I’m just a guy who has been working in the industry now for about 18 months. I’m no expert and I’m certainly no senior engineer. However, this question has plagued me for a while and I’ve asked, and read and mulled and now I’m finally ready to share my thoughts. Hopefully they are of some help to you.
An experienced software engineer, or any professional can feel just as lucky as they come to a problem they've seen before, and solve it swiftly.