Tips for Becoming a Software Engineer: Hands-on Experience

It is impossible for a trainee software developer to become a trustworthy professional in just one year. However, your first year in programming may bring you many valuable lessons and insights. What to expect if you are starting your way in programming? What tips does a novice developer hear from senior colleagues every day? That’s what we’ll talk about here.

Let me start with a quick intro. I became involved in software development a bit more than a year ago. Having decided to learn to program, I applied for an intern position at Mad Devs. As an intern, I got my first experience of software development teamwork in a real project. After that, I continued to work on internal and commercial projects as a Junior Frontend Developer.

This article is not a bunch of guidelines for all beginners in development. I am not a skilled mentor who can teach something to new programmers. I am still a new programmer myself. However, if you are just starting your career in IT, or considering it, you may find my experience helpful.

Lesson one. Communicating with your team

Perhaps you still follow the popular misconception saying that communication skills are not required in the IT industry. Many people still think that programming is all about coding. In fact, this is not the case. Let’s find out why.

Software or application development is a complex process involving many people: frontend and backend developers, DevOps engineers, designers, project managers, QA professionals, and customers. Everybody needs to understand the general direction of work, and also to discuss the details of specific tasks, agree on deadlines, and sometimes resolve conflicts.

Almost 50% of a developer’s workday is busy with communication: software engineers participate in stand-ups, team calls, working online sessions. These sync-up practices ensure that development is done in the fastest and most effective way. Even freelance developers have to take their customers on calls to agree upon details of their projects.

If communication isn’t your strong point, don’t worry, you can learn what you miss. Communication is a skill that can (and should be!) developed. Below we will talk about some specific communication problems in teamwork. For now, I would like to recommend two books that will help you master the art of communication:

• Nonviolent Communication: A Language of Life, by Marshall B. Rosenberg
• Crucial Conversations: Tools for Talking When Stakes Are High, by R. McMillan

Lesson two. Taking responsibility

This is what Uncle Bob writes about responsibility in his book entitled “The Clean Coder”:

“Professionalism is a loaded term. Certainly it is a badge of honor and pride, but it is also a marker of responsibility and accountability. The two go hand in hand, of course. You can’t take pride and honor in something that you can’t be held accountable for.

It’s a lot easier to be a nonprofessional. Nonprofessionals don’t have to take responsibility for the job they do — they leave that to their employers. If a nonprofessional makes an error, the employer cleans up the mess. But when a professional makes a mistake, he cleans up the mess.”

When a developer picks a task from the backlog, he or she must finish it. And “finishing” means the delivery into production, to real users. In other words, the task is not finished if has been submitted for testing. The task becomes completed after the changes are tested and deployed in production. If your feature is available to end-users, it has been delivered, not earlier than that.

This means that the developer is responsible for the feature, from start to finish. He or she has to find a solution, go to the backend developer, create a task for him or her, test it, send it to the responsible persons for testing. He or she also takes the responsibility to report the problems on time, ask for help from senior colleagues, remind them to check a pull request, warn them if the deadline needs to be extended.

Such things, as a rule, can be learned and adopted as a philosophy from senior colleagues who are experienced programmers. And, of course, you should read Uncle Bob’s blogs and books. For example, here’s his famous talk, where he formulates the programmer’s oaths.

Lesson three. Asking for assistance

Being a junior developer, I constantly turn to my colleagues to ask for advice, help, or feedback. Sometimes I might even be annoying while bugging them on everything, constantly.

In this case, I have a choice. The first option is to decide not to bother my colleagues and try to solve the problem on my own. As a rule, it takes a lot of time and often results in extended deadlines. In a real-world project with firm deadlines, it is not the best solution. The second option is to overcome the fear of disturbing a person and solve your problem in a more efficient way and much faster.

Here is a short instruction on how to properly ask for help:

1. Try to resolve the problem on your own. Most likely, you will find a good enough answer on Google search results. Do not spend more than 30–60 minutes on it.
2. Try to describe the problem as if you need to explain it to a colleague. At this stage, the answer can appear all of a sudden. This technique is called “duck debugging”. Do not spend more than 60–90 minutes on it.
3. If you can’t find a solution by yourself, write to your colleague and ask if he or she has a time slot during the day to help you. Briefly explain to them what kind of problem you faced.
4. When your colleague has agreed to help, tell him or her about the problem in more detail. Give him or her as many facts as possible, provide messages in the console, logs, etc. Share the outcome of extensive googling, explain which solutions you have already tried to solve the problem.You may also describe the problem and send it to your team’s chart or #development Slack channel. Perhaps one of your fellow software engineers will help you find the solution.

Ask a lot of clarifying questions. If you don’t understand something, don’t be afraid to seem stupid, ask again and again until you understand. This is how you save your and other people’s time. After all, if you don’t understand something and haven’t asked your team about it, you will have to go back to it later and spend more time on finding the solution.

Feedback is another important aspect. Beginner programmers cannot evaluate the work they do objectively. That’s why you should regularly ask your teammates and senior colleagues for feedback. This will help you identify your strengths and weaknesses, and understand what to work on to improve your programming skills.

Lesson four. Talking about problems

In a software development team, it is very important to talk about problems on time. The sooner you voice what is bothering you, the sooner you can get help to solve the problem.

It means that when you:

• realize you’re not getting over the task,
• have spent too much time on a specific task,
• understand that you’re close to breaking a deadline,
• don’t even know where to start, are blocked by circumstances or other team members,

JUST TALK about it!

The software development process is aimed at the early detection and solving of possible problems. Daily stand-ups and regular team calls help keep everyone on the same page and take action on time.

Stand-up is a practice of describing what you did yesterday, what you will do today, and what problems you are facing at the moment. The “problems” column exists there for a reason. Your task is to report problems. The task of all working processes and individual roles in the team, such as Project Manager (PM), is to help you solve these problems.

Every time when you keep your problems to yourself, there’s a PM crying somewhere out there — it’s your PM.

Lesson five. Being afraid of making a mistake

I have a problem — I am afraid of making mistakes. I am afraid to miss the deadline, let my colleagues down, and disappoint the customer. This fear prevents me from starting new tasks because I doubt if I can cope with them. My professional development gets stalled because I am afraid to take unfamiliar tasks with huge research part.

If you are also afraid of something, it is normal. You need to understand a few things. They may seem trivial, but they will help you calm down and allow yourself to make mistakes.

First, it is impossible to know everything. Especially in the modern IT industry, where things are changing very fast.

Secondly, there will be errors anyway. Developers are not robots, they can’t write perfect code all the time. But it is very important to strive for this, to learn from mistakes in order not to make them again.

Thirdly, you can’t develop professionally without making mistakes. By making mistakes, we gain invaluable experience. All the lessons described in this article are learned from the mistakes made me and my fellow coders.

Robert Martin wrote about mistakes in his above-mentioned book, “The Clean Coder”:

“Of course you are right. Software is too complex to create without bugs.

Unfortunately that doesn’t let you off the hook. The human body is too complex to understand in it’s entirety, but doctors still take an oath to do no harm. If they don’t take themselves off a hook like that, how can we?”

“Are you telling us we must be perfect?” Do I hear you object?

No, I’m telling you that you must be responsible for your imperfections. The fact that bugs will certainly occur in your code does not mean you aren’t responsible for them. The fact that the task to write perfect software is virtually impossible does not mean you aren’t responsible for the imperfection.”

Lesson six. Working for results

Many different tools and methodologies are used to optimize teamwork in software development. You have probably heard about OKR, Agile, SCRUM, and many other approaches to software development. To some people, all these methodologies might look redundant and time-consuming. However, you need to keep your entire team focused on the defined goals and priorities. This makes the development process flexible and structured.

The team should understand the goals of its work, know what kind of problem it solves, and what value it brings. Otherwise, it is monkey business — work for the sake of work, sitting in the office waiting for the end of the day.

Therefore, you should always strive to learn more about your project’s business goals, even if your manager does not actively communicate them to you. Initiate a conversation on it, learn more about the customer’s problems. Come up with additional scenarios reflecting the end-user behavior. Dig deeper into every aspect of the product, and find out what else you can do to improve the end-user experience.

In accordance with my older colleagues' advice, I constantly ask myself “Am I doing shit right now?” I think this might work for you as well.

Lesson seven. Task Estimation

The ability to evaluate tasks is a kind of art, it’s really hard to master. However, there’s one simple practice that will solve half of your problems with estimating tasks — never agree to deadlines you are not sure of.

Once again, let’s turn to “The Clean Coder” book, where Uncle Bob gives an example of the dialogue about deadlines between the developer and the manager.

Mike: “Paula, I need the login page done by tomorrow.”

Paula: “No, Mike, that’s a two-week job.”

Mike: “Two weeks? The architects estimated it at three days and it’s already been five!”

Paula: “The architects were wrong, Mike. They did their estimates before product marketing got hold of the requirements. I’ve got at least ten more days of work to do on this. Didn’t you see my updated estimate on the wiki?”

Mike: (looking stern and trembling with frustration) “This isn’t acceptable Paula. Customers are coming for a demo tomorrow, and I’ve got to show them the login page working.”

Paula: “What part of the login page do you need working by tomorrow?”

Mike: “I need the login page! I need to be able to log in.”

Paula: “Mike, I can give you a mock-up of the login page that will let you log in. I’ve got that working now. It won’t actually check your username and password, and it won’t email a forgotten password to you. It won’t have the company news banner “Times-squaring” around the top of it, and the help button and hover text won’t work. It won’t store a cookie to remember you for next time, and it won’t put any permission restrictions on you. But you’ll be able to log in. Will that do?”

Mike: “I’ll be able to log in?”

Paula: “Yes, you’ll be able to log in.”

Mike: “That’s great Paula, you’re a life saver!” (walks away pumping the air and saying “Yes!”)

Do not overestimate yourself and do not overpromise, otherwise, you will get sleepless nights, a lot of overtime, and an angry PM.

Afterword

These seven lessons are learned during my first year in the IT industry, my first experience of working as part of a software development team. It was a difficult year, full of insights, but it has discovered a new amazing world to me. The way starts here, but what’s next? It really looks promising so far.

Acknowledgments

Finally, I would like to give credits to all my teammates and mentors and say special thanks to Denis Grushkin, Emir Sabyrkulov, Vladimir Shebarshov, and Alice Jang. Thanks for your time and patience, now my mommy says to everyone that I’m a developer, and I write such smart articles =)

Thank you for your attention!

Previously published at blog.maddevs.io.