Last year, I had a talk with a friend who was looking forward to starting his first Software Developer job. He was pumped about all the things he gonna learn. It was uplifting to listen to him.
He described how he wants to spend the whole day building new frontends, new backends, new whatever. He will not leave his IDE. He will be happy.
During our further conversation, I am not sure if I crushed his dreams and made him reconsider his life choices. I am really not sure. In short: I told him about all the meetings and other things I have in my everyday life that keep me away from the IDE.
This conversation really left an impression. In Retrospect, it probably made me think more than myself. He probably already had shrugged it off after another Gin Tonic.
I somehow recognized my former self. The once hyper-motivated junior that wanted to solve everything with code. (Clarification to my boss: Of course I am highly motivated - each and every day).
I barely remember any details from the interview that lead to my current job. What I remember, besides a question about the basics of JSON, was that my current boss asked me “What share of your time do you expect to be coding?”
If I remember correctly, I stuttered something like “Well, I guess something around 75% would be optimal”. Looking back, I am not even sure how I figured out this number - maybe that was one of the reasons why I got more of a junior role. Who knows?
I think the answer itself was not too bad. Still, I think reality looks quite different. Today, I spent a lot of time in meetings. We talk about requirements, internal and external team collaboration, getting new customers, technical decisions, technical debt, staffing, onboarding people and shaping the products.
For me, the time spent in these meetings is not the main problem, personally I even think this is time well spent. Time invested there prevents a lot of unnecessary effort. The main problem for me is the dead time in-between.
Developing Software is about People
This is my personal takeaway from the conversation: Developing Software is about people.
More often at work, I don’t struggle with the latest nuances of a Framework but with a people problem. We as developers interact a lot with people. We need to find compromises, convince people that our solution is the best, admit that other people’s approach is more clever all while keeping a positive spirit within the team.
Pair Programming is, in my opinion, one of the best coding techniques to share knowledge and to learn new things.
Today’s Software Development is not borrowing the cliche of nerds developing software.
Building software is a team effort involving a lot of tech and non-tech people. Most often the result of our work gets used daily by non-tech people. Over the years, I tried to embrace this nuance of my daily work.
Personally, I enjoy more and more to be part of such activities on top of coding. Finding the perfect solution is rarely be found with code only.
I hope you enjoyed the read as much as I enjoyed talking to my friend starting with Software Development. What I also would enjoy, is hearing from your experience.
What did change for you over the years? Do you share my view or are you disagreeing? Please let me and others have a share in your experience.
You can leave a comment here or on Twitter.
Tweet to @eiselems
About the Author:
