Most people don’t have a clue what we do. Especially management. Most people think we’re code factory workers, just writing code all day. In reality, it is closer to being an artist than it is a factory worker. There’s a ton of thinking, discussion, design, and unfortunately politicking.
Thats interesting. I am one of those people who assumed the job was pretty much just coding all day on some team project. What does your day to day routine look like?
It can vary a lot depending on the day and the company/job. Frequently there are meetings that are update/planning discussions, discussions with one or more other engineers on how to build a given feature, debugging existing code to figure out why it’s not doing the thing we want (which is a different but overlapping skill set with coding).
Ultimately there isn’t really a “typical” day because we wear a lot of different hats. My current job is more coding heavy because I’m at a small startup with only a couple of engineers. In a given week I’m probably doing 10% meetings, 50% coding/debugging/configuration, 20% code review (reviewing other people’s code), and 20% thinking/designing/experimenting with ideas. Those numbers vary a lot though. At a previous job I ended up spending an entire week just doing project management to alleviate my boss’ anxiety over a project (which was somewhat self defeating because it meant I wasn’t getting work done on said project). That job in particular had a lot of politicking and communication which was due to micromanagement.
A lot of what people don’t realize is that we aren’t just building a feature. We’re building a feature while thinking ahead to known or potential future features. How can we build feature A to enable making features B, C, and D easier/better/faster without also making feature E much more difficult or impossible? It’s about building flexibility into the system while also balancing against time and cost restrictions. We as engineers have things that we see as necessary while the business wants more features and it’s necessary to balance the two. At a healthy org that means that there’s a negotiation of priorities between the two forces. If you only focus on the technical stuff, you won’t ship features. If you only focus on the features, how fast you can deliver features will come to a grinding halt. Your system will also start breaking in unexpected ways which takes time away from building features.
It’s kinda a rambly response to your question but I hope it helps.
Fully agree with you. People think anything can be done with Software. But often not really and we just create a work around.
Its always funny to see people think developing is easy and then get shattered by reality. Sometimes you just sit there, screaming for why it doesnt work!..then you see you set the wrong variable.
Sometimes you are an artist, sometimes a high mathematician, sometimes a wizard and sometimes you want to get an axe and hack your computer
Software engineering.
Most people don’t have a clue what we do. Especially management. Most people think we’re code factory workers, just writing code all day. In reality, it is closer to being an artist than it is a factory worker. There’s a ton of thinking, discussion, design, and unfortunately politicking.
Thats interesting. I am one of those people who assumed the job was pretty much just coding all day on some team project. What does your day to day routine look like?
It can vary a lot depending on the day and the company/job. Frequently there are meetings that are update/planning discussions, discussions with one or more other engineers on how to build a given feature, debugging existing code to figure out why it’s not doing the thing we want (which is a different but overlapping skill set with coding).
Ultimately there isn’t really a “typical” day because we wear a lot of different hats. My current job is more coding heavy because I’m at a small startup with only a couple of engineers. In a given week I’m probably doing 10% meetings, 50% coding/debugging/configuration, 20% code review (reviewing other people’s code), and 20% thinking/designing/experimenting with ideas. Those numbers vary a lot though. At a previous job I ended up spending an entire week just doing project management to alleviate my boss’ anxiety over a project (which was somewhat self defeating because it meant I wasn’t getting work done on said project). That job in particular had a lot of politicking and communication which was due to micromanagement.
A lot of what people don’t realize is that we aren’t just building a feature. We’re building a feature while thinking ahead to known or potential future features. How can we build feature A to enable making features B, C, and D easier/better/faster without also making feature E much more difficult or impossible? It’s about building flexibility into the system while also balancing against time and cost restrictions. We as engineers have things that we see as necessary while the business wants more features and it’s necessary to balance the two. At a healthy org that means that there’s a negotiation of priorities between the two forces. If you only focus on the technical stuff, you won’t ship features. If you only focus on the features, how fast you can deliver features will come to a grinding halt. Your system will also start breaking in unexpected ways which takes time away from building features.
It’s kinda a rambly response to your question but I hope it helps.
Hey collegue!
Fully agree with you. People think anything can be done with Software. But often not really and we just create a work around. Its always funny to see people think developing is easy and then get shattered by reality. Sometimes you just sit there, screaming for why it doesnt work!..then you see you set the wrong variable.
Sometimes you are an artist, sometimes a high mathematician, sometimes a wizard and sometimes you want to get an axe and hack your computer