There are millions of people like me, taking this turn, and even more, will come along as the demand of software developers only seems to be growing. That’s why, in this article, I would like to share with you my 10 tips on starting a career as software engineer – the things I wish we were taught in the universities and academies. Take a dive into the mixture of 10 soft-skills that will make our daily work more efficient, especially when working with clients.
Deal with tight deadlines – do the estimations on your own
As an expert, you’re the one who knows how long it would take to finish a certain task. It’s important to take the time to do the estimation. Do it without taking the given deadline into consideration, as it can lead you to wishful thinking. Once it’s done, compare the result to the actual deadline. If it matches – it’s all good. If it doesn’t – evaluate the gains/costs of the two options – doing it right or doing it twice, and try making a reasonable choice, keeping the customer’s values at the top of your mind.
Explain your analyses to the customer and make the decision together. This way, the pressure from the deadline goes away as you made a conscious decision about what you gain and what (eventually) you’ll have to pay later as technical debt.
Take your time to analyze your past estimations
When you are in the beginning of your career as software engineer try answering the following questions and take notes:
• What went well? What didn’t?
• What’s the real reason you didn’t meet the deadline? Is there something you could have done about it?
• What you could have done better?
The only way we can get better is to get into the bottom of the problem. Ask yourself questions. A lot of questions. If the answers don’t come on the surface easily or aren’t clear, break down the questions into more simple ones.
Read the Exceptions messages thoroughly
I’ve heard it many times, you’ve heard it many times, but this still needs to be said. Don’t play the guessing game like “Ahh, snap, I know what it is *closing the exception*. We all do it every day. We are presented with the reason for the Exception and we still try to out-smart it. Reading the message and giving it a minute to sync in will often directly lead us to the core problem and save us the headache.
Exceptions types to research right away
Most of the time, we get what’s needed to resolve the issue just by reading the Exception’s message. Though this is not always the case and it can often turn out to be very time-consuming. Here’s what to do when the message is a) gives you no hint at all and looks like it’s so deep in the dark, you don’t even know what it’s trying to tell you or b) the message is completely misleading – go straight and google it. It’s highly likely someone else has already struggled with this. We don’t want to reinvent the hot water, do we? Note: this doesn’t work well for technologies/libraries that are too young and/or still have a small community.
Find your role-models within the company
There is always that one workmate who seems to have the skillset you strive for. Go talk to them openly about anything you’re curious about. Afraid that you might annoy or bother them? You’d be surprised to see how much they’re willing to tell you only because you show genuine interest in what they do and how they do it. Finding the right mentor is crucial when starting your career as software engineer.
Make customers’ values your priority
Let’s say you have specific functionality to implement. You finish it. It works, it meets the requirements, it’s all good. On the way to implementing it, you encounter some code that’s written against the established conventions in the team. Yet, you know the customer values “the boy scouts rule” – leave your code better than you have found it. They never push you to stick to it, but when you do so, without being told, it’ll be a small effort with a big win for your relationship with the customer.
Take on more responsibilities
If you think you can do something more than what’s on your agenda – go for it! Even if you are in the beginning of your career as software engineer, people (customers, team-leads, managers, etc.) don’t like to babysit you and they will be impressed to see you’re capable of doing a little bit more than what they expected. This way you gain more trust and they’ll feel more comfortable to rely on you. Of course, it’s not all rainbows and butterflies – by pushing yourself beyond your current capabilities, you’ll screw things up eventually. Make sure to evaluate the risk-reward ratio. When you do screw up – have the humility to admit you’ve made a mistake or an error and do not feel ashamed of it. After all, making mistakes is the way we grow and make progress. Your Project Manager knows it as well. The key point is to make sure you took your notes and next time you’ll do better.
Stay focused during the meetings
Yes, sometimes it’s hard, I know, but doing so validates your intentions to do the best work you can. By knowing more about the problem at a hand it later gives you the opportunity to make suggestions about solving problems you’re not supposed to solve in the first place. When you suggest something valuable, the benefits are huge. People on the other side will love it! What can help you, especially in a remote working environment with kids, is to allocate the timeframe when it is the quietest in the house!
Leave your ego away of your code
As programming is quite a creative job and we’re practically creators, it’s normal to get emotionally attached to what we create (write). Yet, we should remind ourselves regularly that our point of view is not the only right way to do the job. There are many. Even if ours is close to the best one, there’s always a room for improvement. Our work is heuristic and because of that, we should always be open to improvements. By truly believing this, we can accept feedback more easily and learn from it, which will help us enormously in the long term.
Ask yourself questions the moment you get stuck on a task
Let’s say you’re somewhat close to finishing with your implementation. Then, you suddenly notice a tiny edge case where your code might bend. You feel like “ok, I think I know how to quickly handle this”. This “quickly” becomes from a minute or 2 to an hour and a half or more. The further you go, the harder it becomes to give up. As time goes by, you feel worried because you start realizing you are wasting your time. So, what to do about this? Have a plan for this kind of situations up-front! The moment you find the tiny edge case ask yourself these questions:
• Is it this case a real concern?
• Will this ever happen in reality? If so – how often?
• What do we gain if we handle this scenario?
• Given the gains (if any), what is the reasonable amount of time that is worth spending?
Once we answer this final question and we reach that amount of time we set for the task, we must stick to it. If we don’t do this up front, we’ll often get in the “from a minute or 2 to an hour and a half or more.” state.
Overall, the tips I shared above helped me improve my productivity by focusing more on what really matters. They might be slightly different for your team or project, but I believe you will find something relevant to take away and imply in your daily work.
And how about you? What did you learn the hard way? I’d be happy to hear in the comments below!
P.S. We also have some new exciting opportunities opened at the moment for everyone bright and brave enough to face all software development challenges on the way. Check them out and start your career as software engineer now!