DEV Community

Cover image for What do you spend the most time on as a developer? ⏳
Ben Halpern for The DEV Team

Posted on

What do you spend the most time on as a developer? ⏳

This is the second post of the Mayfield + DEV Discussion series. Please feel free to go back and answer yesterday's question as well.

What parts of the software development process and job take up most of your time?

Be as detailed as you feel appropriate. On a day-to-day basis what takes up most of your time?

Top comments (35)

Collapse
 
sanjaybabu profile image
C K Sanjay Babu

I mostly spend my time in refractoring and finding the root cause of bugs and fixing them. Sometimes, its really frustating when analysing for the cause of the bug, but once I find it, I am super satisfied & proud.

Sometimes I even picture myself as Sherlock who is solving another one of his mysterious cases! I know this may sound lame, but adding a fun context like this kept me motivated when going was tough!

Collapse
 
joelbonetr profile image
JoelBonetR 🥇

Seeking for bugs and solve them is one of the things I like most.
Don't get me wrong, I don't ever create bugs on purpose because if you already know it's not funny 😂

Collapse
 
isaacdlyman profile image
Isaac Lyman • Edited

Finding the information I need to do my job. Seriously, as a senior dev that's 70 to 90 percent of my time. It takes many different forms:

  • Poring over documentation to find an implementation detail
  • Googling for hours when the documentation is missing something
  • Working the corporate hierarchy to find the person with the permissions I need
  • Clarifying specifications with a product manager
  • Getting feedback from the team on a proposal or a process I've documented
  • Reproducing and diagnosing bugs at various deployments of my team's app

And then sometimes I've got the information someone else needs to do their job, so I'm helping them. If I spend even half my day coding and knowing what I'm doing, that's a really efficient day.

Collapse
 
thevinitgupta profile image
Vinit Gupta

An insight into the life of a senior developer 😅
I don't know why, but I find this exciting

Collapse
 
isaacdlyman profile image
Isaac Lyman

Sounds like you're headed straight for engineering management then 😂

Thread Thread
 
thevinitgupta profile image
Vinit Gupta

Maybe someday 😅
Currently not even an SDE yet

Collapse
 
dabee profile image
Rich

Technical documentation is notoriously bad. Often I see terse docs, empty docs, or highly technical docs that ignore new users. Insecure managers that don't understand the scope of their user base, push for highly technical documentation that can easily confuse most people. This is why VCRs always flashed 12:00.

Collapse
 
brunoj profile image
Bruno

In examining my process, I spend most of my time futzing with stuff. That's the best way to put it.

Basically a task is somewhat done, but the last mile of tests, edge cases, light refactoring — once it essentially works already takes up much more time than actually getting it to essentially work in the first place.

This may be a bad answer. Looking forward to reading what direction other folks take this question in.

Collapse
 
isaacdlyman profile image
Isaac Lyman

This is a great answer IMO. And it really paints the picture of what kind of dev you are: mature enough to know that "it works" doesn't necessarily cut it, experienced enough to visualize what else remains to be done, persistent enough to get it across the finish line. I think those are essential traits in a senior dev.

Collapse
 
jsn1nj4 profile image
Elliot Derhay • Edited

Have to agree. Putting that time and effort in is no joke, especially when the fun part is already long done.

Collapse
 
chasm profile image
Charles F. Munat • Edited

I spend most of my time coding because I'm senior enough to get away with it. Most of the other devs spend less than 50% of their time coding (my guess). Some of that gets eaten up by socializing (it's amazing how many people think that work is a social club), but most of it is process, and most of that process in my view is actually failing to help or even making things worse.

One of the ideas I've been promoting is that of micro-apps. Breaking a large monolith down into small apps -- small enough to be handled by a single dev -- and then putting those behind a reverse proxy like nginx. (I'm talking front end applications in front of, say, microservices).

Use a pubsub system to communicate between apps, pages, devices, etc. -- even components -- with BroadcastChannel, websockets, and/or server-sent events. Totally decoupled. I've done this for a large enterprise (a bank) and it works beautifully.

There are many benefits to micro-apps, including scalability, robustness, security, etc. not to mention the ability to completely refactor individual apps easily or to experiment with new technologies. To the end user, it's all transparent.

But one of the biggest benefits is the ownership model. One dev per app (with a buddy looking over their shoulder so that they can step in if the dev disappears, and as a sanity check). But in each micro-app, a single dev owns everything. So that dev "owns" the code. Period.

This eliminates the tragedy of the unregulated commons and also encourages the sole developer to write the best code possible as everyone will know who wrote every line of code in that app.

It also greatly reduces process. With proper leadership (someone has to enforce the contracts between what are essentially black boxes -- micro-apps are similar to actors), a large app can easily be built quickly and efficiently, with much better Dx. There's much more to this than I can explain here, but hopefully others are trying similar things...

Collapse
 
janmpeterka profile image
Jan Peterka

Recently in one of smaller projects we are starting I spent most of my time doing refactorings. Our first code was not really great, part of data design was just not great (eg. we had table users, but we found out we need to split it to users and members, as we want one user to be member of multiple groups). So it was splitting tables, writing migrations, changing code in most of the project and all the time testing if all is still working as before. Which lead to many more small changes here and there, as I stumbled on something that was so six months old code we don't use here anymore.
But the feeling that our code is much more future-proof, cleaner and sane makes it really time well spent. Oh, and also I had to read SQLAchemy docs like ten times to try to really find out what decisions make sense.

Collapse
 
seek4samurai profile image
Gourav Singh Rawat • Edited

Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS -> Solidity -> JS/Nodejs -> AWS...

Collapse
 
jeremyf profile image
Jeremy Friesen

I spend a lot of time reading code and depending on the task at hand, I might do a bit of light refactoring. But I have to check myself to not try to both fix a bug and tidy up the neighborhood. Which means keeping salient the concept of an atomic commit.

Collapse
 
joelbonetr profile image
JoelBonetR 🥇 • Edited

As Tech Lead/Lead Dev it happens like that to me:

Meeting, explain someone any workaround to solve a ticket/issue, code review, answer some call to explain someone else how to solve whatever or to clarify something, another meeting, email from client asking things, analyse those things and document them to answer properly... that's why I set myself on "disconnected" on MS Teams at certain point of the day so I can have some time to code 😂

Collapse
 
nombrekeff profile image
Keff

Code reviews and managing people in my team takes away quite a bit of time on a daily basis, but lately it's excesive meetings which are taking away a lot of time from "real" work.

Coding itself is one of the things I spend the least amount of time doing now a days, I miss that somewhat!

Collapse
 
barelyhuman profile image
Reaper

Mostly reading, not just my code by code from other developers, primarily because it helps bring perspective of ways something can be done.

Other than that, I always have a window with hacker news + other developer blogs I like to read.

Collapse
 
sirtalllpaul profile image
SirTalllPaul☀️

As a junior with less than a year experience my day pretty ouch consists of creating forms and working out the best events (mainly datagrid events) for the job.

I've been tasked with trying to make a Xamarin app recently which is going to be huge for me, both excited and scared 😂

Collapse
 
jonrandy profile image
Jon Randy 🎖️

TBH - usually working on personal projects in my head... which my mind keeps jumping back to instead of working on the development I'm supposed to be doing. Most of the time it feels like trying to read a book whilst the TV is on - I end up not being able to fully focus on either

Collapse
 
arndom profile image
Nabil Alamin

some days: code -> code -> code -> bug -> attempt resolution -> rest-> resolve -> repeat

other days: PR / Code review -> meetings -> learn -> rest -> implement -> repeat

pigs in the air: I'll let you know what I do then when that happens

Collapse
 
joset98 profile image
joset98

I spent my time finding bugs, refactoring code fragments and convert to components to be more flexible (usually is code that workmate did), meetings to know what exactly is my task or where is the origin of the bug or where is the that i need fix

Collapse
 
deciduously profile image
Ben Lovy

Wrangling data. Serializing, deserializing, thinking about data representation. So many boundaries to cross.

Some comments have been hidden by the post's author - find out more