Soft Skills for Software Engineers — Part 2: Get Things Done
If you want to be a software engineer — you need to have tech and coding skills. If you’re going to be a great software engineer and go ahead — you need to add soft skills.
In the first part of the article, we started discussing the importance of soft skills for software engineers and focused on communications, their role, significance, and pumping methods. I would recommend reading it if you are haven’t yet.
Get Things Done
This part will look at most software engineers’ work to solve various customers' problems and issues. And the customers expect from us the best results— sometimes they call it “everything’s need to work right and fast”. So, inside our team, we tried to collect actions that we need to do to deliver the best results and call it almost like a great well-known framework — Get Things Done. As a result, our list of actions and practical approaches have many common things with the original David Allen’s framework. No wonder because we were inspired by it. But after all, this article is practical approaches and actions for software development that help deliver results to customers in our coordinate system. So, let’s review the constituents of this approach that we try to follow and develop in our team.
Gathering Requirements
During the development of new functionality, you as a software engineer often have to choose whether to make it more quick and performant or more maintainable, more reliable, or more secure. For better decisions, you need to collect detailed requirements from all customers and stakeholders. You need to involve them in this requirement collection process, ask questions, and organize some docs to help you understand a better solution in this specific case and make sure that you plan to do the right things. You can say that it’s not the software engineer’s work; it’s a project/product manager task. And you’ll be correct, but not entirely because you, as a tech expert, need to understand what exactly you need to do. So, that’s your area of responsibility too, but yes, maybe from a little bit different perspective. Customers’ vague desires like “everything’s need to work right and fast” should be transformed into a clear list of requirements. Thus, it will be easier to reach an agreement on controversial issues, both in design and during development. Of course, again, you are not a product or project manager, but you need clearly understand what’s your customer want to provide the best and most effective results.
Useful links and how to push skill forward:
- Make notes during meetings with customers, product owners, project managers and transform them into your preliminary plan with action items;
- What problem is the customer trying to solve? What task is the customer trying to perform using the requested feature?
- Don’t hesitate to say, “I don’t have enough information about your requested feature; please provide more details.”
- Share your thoughts and propose different possible solutions and options to internal customers — it’s one of the keys to understanding their way of thinking.
- How to Pick the Right Software Architecture From the Start
- Requirements Engineering — Introduction
- Software Requirements Gathering Techniques: A Formula For Success
- What is the ideal mindset for a developer participating in a requirements gathering meeting?
Time Management and Planning
I don’t have time — I need to write code!
How often many of us caught ourselves thinking or heard these words from colleagues. When you have a lot to do, knowing how to manage your time is crucial. But time management is not about time. Time management is about tasks and priorities. How to manage your business to stay productive during 8 hours per day and 40 per week? How to stay in a state of flow during busy times and maintain a work-life balance? How much time do you spend planning tasks and projects? How much time do you have for coding? And do you have time to work with your teammates to come up with new ideas or discuss existing ones?
Managing your time most effectively allows you to focus on what’s essential, get tasks done more efficiently, and concentrate on main and long-term goals instead of wasting time arguing about minor things. Especially considering that working under pressure and still meeting deadlines is pretty much the life of a great software engineer. Customers often want accurate estimates of when work is going to be complete. Thus, you must have a time management strategy.
Useful links and how to push skill forward:
- Use task-managers: Notion, Todoist, Trello, Jira/Confluence (if your company uses it for business), etc. Even just Evernote also can be commonplace for accumulating your tasks.
- Use different techniques like Pomodoro, Eat the Frog, “Must, Should, Want”, Eisenhower Matrix, Descartes Square, etc.
- It would be best if you had time to create a plan. For next day, for next week, for next month. When you have a plan, you always know your next task and your big goal.
- 21 Productivity Methods: Which One is Right for You?
- TED video| Inside the mind of a master procrastinator
- TED video|The Philosophy of Time Management
- TED video|How to manage your time more effectively
Estimations
Yes, work with estimations is an extensive topic, and it deserves a big separate article. So just in short words — yes, it’s pretty hard to do right and strict estimates in software development. Yes, most engineers are not so good at it. And yes, being good at this will make you stand out. Even more — you really will feel better and more confident if feature development time will match with your estimates.
Saying that “is just too complex to estimate” is an easy way out over asking the hard questions on why estimating is hard and how you can get better at it. Estimates will not be perfect, but that does not mean that it’s pointless to estimate tasks in software projects. Estimating helps a team communicate, encourages an agile process, and becomes workflow to be more predictable, fair, and transparent for all stakeholders.
Useful links and how to push skill forward:
- Always remember — you don’t have 40 hours and 5 days per week for coding! Meetings, code review, switching context, testing, asking advice, dependencies in other teams — that’s must be included in your estimations.
- Any development task must be analyzed and evaluated. There may be difficulties, blind spots, etc., but you should do a preliminary analysis.
- You need to research before providing ETA — that’s normal. Take your time.
- Why Developers Should Like Estimates
- 4 Steps to Make Better Software Development Estimates
- Why You Should Do Software Estimates
- Estimating Software Engineering Effort
- Why Software Developers Wrong In Estimating Time (And How to Fix It)
Decomposition
One of the formal terms for decomposition is— breaking something down into its components, which in turn can be broken down into smaller pieces and so on until you are down to the most straightforward possible units. Driven by the need to understand how things work, a vital feature of the developer‘s toolset is reducing a thing into its smallest components. Small items are much easier to predict, understand, and build. Once you have a set of the smallest components, they can be assembled back into the original thing or into something completely new. In simple terms: if something seems so big or complicated — decompose it to small and precise. That’s always works!
Useful links and how to push skill forward:
- Decompose to cases when each subtask has estimations of no more than one w/day and even less if it’s possible. Simple tasks are always more manageable.
- Write step-by-step plans and mini-roadmaps (each step is one or a few simple sub-tasks) for all significant issues and user stories that bigger than 5–7 w/days — because it values more than half of the standard Sprint size.
- Practice in the discussion of your decomposition plans with teammates. Quick review and fresh look are always constructive.
- Learn and try to use different Task Decomposition Methods
- Why Decomposition Matters in Developing Software
- How detailed should tasks be within a user story?
Problem Detecting and Solving
It might be sounds strange, but software engineer work is continuously resolving and fixing problems. It starts from bugs in existing apps, tools, and projects and finishes when customers don’t know what they want, but they have issues with some processes and try to solve them using software development. So, software engineers solve problems, and that’s why they need to be creative, proactive, good in planning, and others than mentioned here — because customers wait for some solution. No, customers wait for the best solution for their process and business. Problem-solving is a critical skill that a great software engineer must have because it’s the sense of work.
Useful links and how to push skill forward:
- Create a common and straightforward run-book that describes steps that must be done or checked from up to bottom for detecting the source of the problem.
- How To Develop Your Problem Solving Skills
- The 5 Problem-Solving Skills of Great Software Developers
- How to think like a programmer — lessons in problem-solving
- The 3 Minute Problem-Solving Strategy
- Four steps to solving any software problem
Clear Documentation
Documentation is the start point and finishes point of any software project that will be developed. Writing documentation is one of the understated skills software engineers must have, but 99% don’t like it. But someone who has pretty good enough experience in this area clearly understands how important it is to create documentation along with the project, even before the start of the development stage and up to the enhancement of the project. Taking that extra time to write proper documentation of what you worked on will save vast amounts of time in the future for your customers, your teammates, for yourself.
Useful links and how to push skill forward:
- Remember: self-documenting code can’t completely replace documentation. Can make it easier — yes, full replace — definitely no.
- Enroll in a short course by Google: Technical Writing | Google Developers
- Watch the 10-min video and check this strategy writing effective documentation
- Use some patterns, templates accepted as a standard in your team/department/company, and don’t hesitate to improve it.
- Should Developers Write Documentation? Yes, and Here’s Why
- How to write good software technical documentation
- Why programmers don’t write documentation
- Technical Documentation in Software Development: Types, Best Practices, and Tools
As Summary
These skills and approaches are not an attempt to re-write the amazing existing Getting Things Done framework. It’s just how we see steps and actions to work with daily tasks and achieve excellent results in professional development as software engineers and deliver maximum benefits to customers. We’ll hope that you find some practical advice and solutions that help to grow. So, in the next part, we’ll analyze another complex item — mindset and its constituents…
