Hello developer, how are you? Has anyone asked how your day has been today? To be a proficient software engineer, we find ourselves in an ocean of skills that are required for the job: each company has its tech stack, its way of working and its culture. Which skills should you focus on? Which ones should you have?
Well, commonly, skills are divided into “Hard Skills” and “Soft Skills” and we are normally assessed based on a combination of them. Sometimes, it is hard to see how soft skills are seen in practice, especially when engineers are not used to paying attention to them. In this article, I’ll show you a few attributes, methods and tools that an engineer can apply to better connect soft and hard skills in day-to-day assignments.
See more than tasks
Each activity, each task, and each development story is involved in a much broader environment. They did not arrive at your desk to simply be “coded” and never seen again. In order to help you understand all of this better, I draw an ideal line of thought in eight steps. They can either be taken as a method or as a simple reference.
Understand and buy the idea
The first step should always be to understand, but in addition, it is extremely important that you agree with how the task will be developed. It’s likely that developing against your will won’t bring good results.
Raise the acceptance criteria
This is one of the most overlooked steps in development. After all, you already know what to do, so why waste time writing the criteria down? It’s simple, how can you ensure that your understanding is the same as other stakeholders’?
Abstract and materialize
It’s normal to make some modifications to the original idea while transferring it to code for a set of reasons: ease of understanding, performance and feasibility. So on this step you see through things like how to model it in the database, how to make the logical models in the code, how they interact and how to insert/consult the information that the application requires.
Plan and architect
You might have heard that there is more than one way to solve the same problem. This step is when you select which solution will be applied and should be followed. Document, design and compare different solutions to achieve the best result.
Develop (code and tests)
Now it is the time for actual code typing: follow the development standards, do the necessary tests and apply your knowledge.
Review and analyze
Doing code review is an awesome practice, not only to increase code quality, but also to share knowledge with your peers. Pay close attention to cognitive complexity and redundancy and involve other team members.
Now that everything is ok, you must seek the approval of the PO/client. It is very important to correct/adjust whatever is necessary before you consider this task done. Even if you are not blocked to start another task, try to have the tasks approved – even better released – and do not accumulate things to be approved, because in the future this can lead to a big refactoring.
Look at the whole project
Always keep in mind how the backlog is doing: what has already been done, what still needs to be done and what the deadline is. Now you must reflect if the planning is going as planned or if it needs adjustments.
With this flow in mind, we can think of the characteristics that a developer must have to perform better.
Technology is an ever-evolving field, so there’s an important role in the tools we programmers, use and the things we learn in our careers. Good engineers understand what is good for them and what is good for the project; they do not accept easily, but also do not deny everything; they are virtuous and are aware of their choices. However, there are a few types of behavior that happen very often and catch my attention:
- New libraries and frameworks being responsible for better code: a folder structure, separation of responsibility, use of Design Patterns are some of the items that should govern the quality of what you write. I use libraries and frameworks wisely as a tool and not as a dictator;
- External libraries for every simple feature: with a stronger open-source community each day, we have tons of libraries to use. This does not mean that you should adapt every part of your code to fit them in. Readability, code scalability and vulnerability exposure matter, balance benefits and caveats, and don’t let a library guide your code structure. It is not because you are using a third-party library that you should outsource the responsibility. Be aware of the impacts it brings;
- Courses are didactic and just that: many of the video classes and courses that we have available make us believe that we do and develop things quickly and easily with “new technologies”, but don’t forget that developing is much more than just “typing the right words in an editor” as mentioned at the beginning of the article. So when taking a course, learn the content, but also learn how to insert it into your own world and not the other way around;
Be thorough with your deliverables
Many engineers don’t see all the edges of what’s being developed and sometimes we need to try to sabotage ourselves to discover these limits. When developing, we often only take into account the acceptance criteria raised in advance, but forget to evaluate the different ways a user can interact with the application. Do not only think about the ideal path, but also in all these alternative paths that a user may experiment with.
A few argue that this should be the job of a UX/UI designer. Delivering a top-notch, high-quality product is a team effort. Although the initial requirements and specifications are the go-to guide for the application implementation, we just find out many details on the go. So pay close attention, be open-minded and thorough with deliverables.
Understand project management concepts
Coordinating, planning and executing a project is the job of a Project Manager. You must be thinking that a developer shouldn’t even be concerned with this, and you are kind of right, but even if it is not your main concern you are co-responsible. It is very naive to not even know what a PM does.
In the relationship between PMs and engineers, there are times when an engineer should delegate functions to their PM and vice-versa, but how do you do this if you don’t know what they do? Or even if they are available for you? Ask! Help! You are also able to assist them or even delegate tasks that can help with any project.
Release and team management skills can be reflected within your code: branch naming, commits format, git flows, etc. Know how to use this in your favor.
Track your time
During years of work, I have noticed how hard it is to keep track of time: “I need to ignore people to stay focused and meet deadlines”,or “I didn’t even notice the time passing”.
Always keep in mind that you need to divide your time to perform all development steps and not just time to “type code”. Each person is different, so it works better if you find your own way around it, either by setting goals, or using time tracking tools, just be creative. Don’t focus all your time on just one thing, otherwise the others will become your weaknesses.
Technology develops very fast. It’s amazing how software development has changed in such a short time, so we have to accept that the way we work today may not be the way we will work tomorrow.
But keep in mind that not everything new that comes out will become the new standard. Be aware of the tools you choose to work, apply critical thinking on their pros and cons, and avoid choosing them just because they’re new.
Since we need to adapt to the tools we choose, why can’t we also adapt the use of what we choose to work with? For instance, here at Cheesecake Labs, we wanted to follow gitflow together with tracking done by Jira’s smart-commits. In this case, we changed the way to name branches and we also developed an open-source tool to help us add the smart-commit information in a more agile way. This does not mean that we are doing it right or wrong, or that we do not follow the gitflow or smart-commit guidelines, but rather that we adapt our reality and what we believe in so it becomes the best way to make it work.
Take a step forward
All the points above are soft skills. I wanted to highlight how they have a direct impact on our day-to-day job tasks – and even on interviews – and that many engineers don’t take them into account. Problem-solving, systemic vision, adaptability, resilience and patience are the most common words that we see, but they are not always known or have exemplified how they reflect practically.
Making it happen just depends on you. Evolution is never sudden. To grow, just take a small step a day and over time you will be better. Always take a step forward!