This is page three of the online book "How to Become a Good Software Engineer: Advice from Programmers from Facebook, Amazon, Microsoft and more".
Table of Contents:
- What makes a good software engineer?
- How to become a good software engineer
- Tools of software engineers
- How to develop problem-solving skills
Dmitry Fedorenko uses the “Getting Things Done” practice. It is a productivity system developed by David Allen.
If you are in a lead position you will need to work with people more and more. To simplify this interaction, Alex Khismatulin recommends calendly.com. He allocates blocks of time in which colleagues can reserve meetings with him. When invitations come, he decides whether to accept the meeting or not. This minimizes the process of agreeing on the available time of two people.
[DS: A good example was how I arranged to meet with Alex for an interview for this book. He immediately agreed to meet for the first, March edition, but something made it difficult for us to choose a date for the meeting. When I approached him with an offer to participate for the second version of this book, he gave me a link to Calendly and we had an interview the same week.]
When the number of assignments outside of projects’ backlogs increased, Khismatulin started using a to-do app to keep track of them [any mature app will work; try todoist.com]. He collects all the assignments and when he has a free block of time he picks one from his to-do list to work on.
[DS: I use timeblocking and a personal framework to eliminate context switching during the work day. It boils down to creating uninterrupted blocks of outputs in the first part of the day, and blocks of input and communications in the second part of the day.]
Invest time in learning how to use debuggers. Debuggers are very helpful in quickly understanding what’s going wrong. This will help in resolving bugs and in development when the code stops working the way you want it to.
When a programming language-specific debugger is not enough, debug a problem with platform-specific tools. These are the Unix/Linux debugging tools that Denis Bazhenov uses:
- strace to debug interactions between processes and the Linux kernel
- ltrace command can be used to intercept and record the dynamic calls made to shared libraries
- pidstat reports statistics for Linux processes such as I/O, CPU, memory
- tcpdump displays network packets being transmitted or received over a network to which the computer is attached
- Unix sar (System Activity Report) used to report on system loads, including CPU activity, memory/paging, interrupts, device load, network and swap space utilization.
- Unix lsof (list open files) used to report a list of all open files and the processes that opened them
- vmstat (virtual memory statistics) is used to collect and display summary information about operating system memory, processes, interrupts, paging and block I/O.
The advantage of these diagnostic tools is that they allow you to understand what is happening with the application, regardless of what language the application is written in.
You can also apply analytical debugging. It is a way to ditch debuggers and just think about what went wrong and what caused issues.
The advantages of analytical debugging are:
- You are more likely to find the source of the problem than its symptoms
- You will grow your understanding of the project
- You can find accompanying bugs.
The disadvantage of analytical debugging is that it takes many times longer than debugging with tools.
Next page: How to develop problem-solving skills