How I Work as a Software Engineer
How I Work as a Software Engineer
Learning is such a huge part of software development - there's quite a learning curve. I've adapted lots of methodologies that I've learned to my typical work day.
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
Learning is very big part of software development because technology advances very rapidly. Swift changes create new knowledge to acquire, though we have a lot to learn anyway. As a result, we constantly try to learn software development through books, articles, posts, conferences, and videos. We all want to learn about the best ways to do our job. Nevertheless, applying theory to practice isn’t that easy. I’ve been trying to apply many of modern or fundamental methodologies to my daily job. In this post, I'd actually like to share how I have adopted these methodologies to a normal working day. This post is meant to be updated over the years.
As I’m describing my day, let’s start with the morning. I first look at a bunch of graphs or dashboards. These charts simply show me that everything works as expected for the system(s) that my team own. You might wonder why I don’t have alarms for anomalies. I have those alarms, but these charts are a high-level view that may not be captured through alarms, like the relative drop in three consecutive days or unexpected increase in the last few days. If something seems to be off the road, I quickly try to confirm whether it’s a real problem or not. If it’s a real problem, then I dive into the rabbit hole. This shouldn’t hopefully happen too often. After I’m in the safe zone, I go through e-mails to find out anything surprising or urgent. The next thing I do is planning.
I mostly do a simple planning for my day. Daily planning means looking at which tasks I have and re-order them according to their prioritization. Depending on the environment, you might also want to do this with your team. Sometimes, I also do some broader planning like two weeks, a month, a quarter, or even a year. I try to divide all planning work into days; otherwise, they have a snowball effect. After all, the planning work results in either planning board or roadmap along with some reference documents. I keep roadmap and planning board separately. The roadmap is big boxes over a quarter or half a year whereas the planning board is detailed tasks over the next two weeks or a month. The roadmap makes it easy to show the direction of system(s) to management. On the other hand, the planning board shows current status for developers. The next thing is coding. Yay!
Coding starts with designing and designing well. The design phase for me consists of doing some board work with a pen and an understanding what and how something needs to be done. I tend to ignore problems up until they become real (YAGNI). It doesn’t mean that we don’t consider near future or long-term design choices. I generally write up everything, share with my teammates, and get feedback on my design. In certain cases, I need to refactor the design and consider my options. Another aspect is to review others' designs. It’s generally harder to review as you need to find and possibly suggest changes.
Later, when the design is ready, I start thinking of implementation. Applying pre-designed code is easy depending on the level of details. I generally postpone details like class design to implementation. Yet, I still do class-level design if I’m changing the core of the system. After the design, I write the code per class and with its unit tests. I generally follow a bottom-up approach. I implement from the least dependent class to the most dependent class. Once I’m done with implementation, I run smoke tests if we have any and then add a new one. Finally, I send a code review request along with the docs and necessary reports like coverage. Obviously, I send small reviews without docs and minimal explanation.
The code review process is very decisive for code quality as well as for sharing common knowledge. The process gets easier for the sender within years while his or her vision of software development improves. I have been learning from code reviews a lot. The code review discussions provide very good insight and enforce applying well-known principles. Again, reviewing is harder than writing the code. I need to get into the mood before reviewing someone else's code. So, I spend some time in places like Hacker News, DZone, and more. By the way, I try to stick to code review guidelines, but sometimes I fail to do so because of the rush.
In this post, I have tried to outline my day. It consists of looking at dashboards, planning, design, coding, and testing. I didn’t consider meetings here or things like handling system alarms. There are probably many things I didn’t mention like deployment and automation. I hope to add more details to this post later on. I am open to any feedback.
Published at DZone with permission of Yusuf Aytaş , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.