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?
Oldest comments (35)
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.
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.
Have to agree. Putting that time and effort in is no joke, especially when the fun part is already long done.
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:
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.
An insight into the life of a senior developer 😅
I don't know why, but I find this exciting
Sounds like you're headed straight for engineering management then 😂
Maybe someday 😅
Currently not even an SDE yet
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.
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!
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 😂
Wrangling data. Serializing, deserializing, thinking about data representation. So many boundaries to cross.
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.
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...
Reading through the codebase and making sure that everything is working how its supposed to be. And also trying to figure out what the code is doing if its not my codebase.
Managing dependencies... can you guess what language I code in haha.
But also, taking time to diagram and think things through. Once that's done properly, it's less difficult to execute.
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
Reading code and Googling stuff
Reading code
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
Configuring Kafka lol
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.
Understanding other peoples code
Some comments have been hidden by the post's author - find out more