5 ms·

I recently started working as a programmer and don't like it. I started coding when I was about twelve, and did a CS bachelor and CE master. I like coding. I d

by meuk 9y ago

I recently started working as a programmer and don't like it. I started coding when I was about twelve, and did a CS bachelor and CE master. I like coding. I don't like, however, my work as a programmer. The tasks are just too mundane. I spend multiple days on a RESTful CRUD controller, just because there are so many (IMO useless and even obfuscating) layers of abstraction. The only challenging aspect is the lack of conventions and documentation.

clintonb 9y ago
I didn't care much for my internships and early work. I felt like a cog in a machine. I always wanted to be the guy designing the machine. After a few years I was that guy. Not all entry work has to be mundane, but you learn a lot doing some of that work. The fact that you are spending multiple days, rather than hours, building a controller hints to me that you haven't really mastered that work. Perhaps the task might feel less mundane if you developed a tool/framework to simplify the task itself.
- GarvielLoken 9y ago
  Which you can't use across multiple customers if you work at an IT-consultant company :(. I guess you could make it open source, but then you still would have to convince every team you join to adopt it.
- meuk 9y ago
  I don't have time to implement a tool for implementing CRUD. Wouldn't it be better to not have so many layers of abstraction that you need a tool in the first place? Let me elaborate on what it took me to implement a CRUD controller. I had to implement a repository interface, a respository a context, a service interface, and a controller. Then I had to understand how to write the swagger documentation. Then there is a convention of wrapping every result and exception in some kind of wrapper, which is not documented so I had to figure this out from looking at other controllers. Then I saw a execution path for another CRUD controller which could throw an error which was not in this wrapper, so I had to discuss this with someone from the team. Sure enough, he is in another country, and takes a while to respond. I was lucky it was still morning, or he would have gone home already (there's a 4 hour time difference). Sure enough, this was a bug in the other controller. Then, there is a logging and a monitoring service I had to understand and implement. Undocumented, of course. The controller I used as a reference was inconsistent in monitoring, so I had to discuss this. Then, the requirements for the controller are not clear. The RESTful way of responding to a GET request for a nonexisting resource would be a 404, but the wrapper does not allow this. The reference controller returns 200 OK, but with a null value. So I had to check if this is indeed what's intended. Then I had to figure out how the unit testing framework works and I had to write tests for each method. OK, good practice, but it feels a bit weird, since the unit tests should not use the database while the entire purpose of the CRUD controller is to use the database. So much of the logic I'm supposed to test is mocked. So, I had to learn how the mocking framework works. Then I wanted to write unit tests for the repository, but entity framework crashes when I use an in-memory database. The other developers had a look, but didn't understand this either. The other repository implementations are not tested anyway, so I skipped this. Additionally, visual studio crashed, corrupted my git repository, and I ended up deleting and cloning the whole repo again. Then, I had to configure the project again before it would build, which involves opening the project in an older version of visual studio, then opening the same project in the latest version (some errors magically disappear), and adjusting the IIS settings (which are a mystery to me). I also had a long meeting to attend, and the person who's supposed to get me started didn't have time to help me. In the end, I'm still not quite happy with the actual logic in the controller (it has inconsistencies similar to the controller I used as a reference), but I refuse to spend more time on it.
  - Sammi 9y ago
    Look, work is always pain. That's why they give you money for doing it. The real question is what kind of pain are you willing to endure and why are you willing to endure that pain? Is there a problem that you think needs solving, that you are willing to endure pain for?
  - atoko 9y ago
    Most software is moving data around. All the abstractions you mentioned have a purpose. It makes sense to test each in isolation. For example, a controller whos’ service is a mocked implementation. You can test that your controller and its routes make the correct service calls without ever hitting a database. About the documentation, maybe you’re the one to take initiative and spin up a wiki? Maybe you’re the person that consolidates logging into a reusable internal library? Related to the topic, maybe this is not what you should be doing. There is good work out there, but as cliche as it sounds, you have to show passion for them to find you.
  - marvin 9y ago
    Hope you won't get me wrong here; this sounds to me like the million details required to implement something properly, and certainly a task like the one you describe here would take a workday or two to implement properly. But it does also sound like there are some problematic inefficiencies in the way your company's software stack is set up. Common tasks like logging, caching and error handling should be abstracted away to a separate layer so that you get it for free whenever you implement a new service or endpoint. Don't know if this is old news to you, but check out e.g. [1]. This part about abstracting away rote work and optimizing a stack to be less maintenance-heavy is a learnable skill. The problematic part is that your working environment needs to have it in its culture. It needs to be okay for staff to spend a week here and there tuning a process that's used again and again. This is a big force multiplier which needs to be appreciated by management. I'm in an online banking company with an 18-year history and all the cruft that entails, and we're in aggregate spending multiple full-time positions continually upgrading our infrastructure and practices. Releases used to be one-week affairs that were performed twice a year. Now they're done in half an hour, most of which is verification and monitoring. Etc, etc. [1]: https://msdn.microsoft.com/en-us/library/dn223671(v=pandp.30).aspx https://msdn.microsoft.com/en-us/library/dn223671(v=pandp.30...
gurkendoktor 9y ago
I don't think this is the general frustration with programming that the grandfather post mentioned, it sounds more like you are working on a bad project. There's always been some push-back against over-abstraction, from Rails' "FU Java" spirit to the whole Go ecosystem. It's just that these jobs are much harder to find than the typical Java EE hellscape.
- anonytrary 9y ago
  I have seen some very over-engineered crap coming from GAFAM people, bringing such conventions to modern languages...
gambiting 9y ago
I have similarly started coding at around 12, and now I work as a C++ programmer in games....and love my job. On the other hand, I get paid peanuts compared to literally any other industry. But then all of my programmer friends who work in other industries(and frequently make 150-200% of what I make with the same level of experience) hate their jobs with passion, every time we meet it's just an endless rant on how the job is shit, the managers are idiots and customers don't know what they want. While I look forward to going to work in the morning and build stuff that gives me and others joy, and my managers are also cool. Is that worth dismissing for a higher salary? I don't know, I haven't decided yet.
- cableshaft 9y ago
  Game dev has it's own industry problems, not simply lower pay. You might be working on something you enjoy right now, but that's not necessarily always the case, and there are plenty of crap you have to deal with from clients, publishers, and the like. And the market is severely hit driven, so you could be working 6 months to 2+ years on a project only to see it land like a thud in the marketplace, possibly due to nothing more than a couple reviewers that clearly barely played your game before writing a scathing review, or you just picked a bad week and get completely overshadowed by other games. I worked on 7 games for three different companies, and all of those games failed to find and retain an audience, for various reasons. You spend 4 years of your life working on projects that may as well not have existed, except for your own personal development, and the industry starts to look less appealing. I'm working on software I have much less passion for right now, outside of the game industry, but at least it gets used on a daily basis by thousands of people (not always, I've worked on projects that have gotten binned because clients have backed out or contracts never got signed, or the lead developer quit and the manager decided to outsource the project, in this industry as well). And at least I'm getting paid quite a bit more than I would in the game industry.
commandlinefan 9y ago
> The only challenging aspect is the lack of conventions and documentation. Well, don't forget the challenge of coming up with new, creative answers to why isn't it done yet and why aren't you working faster and what do you mean "reading the documentation", just program, that's what you're paid to do!

by meuk 9y ago

clintonb 9y ago

I didn't care much for my internships and early work. I felt like a cog in a machine. I always wanted to be the guy designing the machine. After a few years I was that guy. Not all entry work has to be mundane, but you learn a lot doing some of that work. The fact that you are spending multiple days, rather than hours, building a controller hints to me that you haven't really mastered that work. Perhaps the task might feel less mundane if you developed a tool/framework to simplify the task itself.

GarvielLoken 9y ago
Which you can't use across multiple customers if you work at an IT-consultant company :(. I guess you could make it open source, but then you still would have to convince every team you join to adopt it.
meuk 9y ago
I don't have time to implement a tool for implementing CRUD. Wouldn't it be better to not have so many layers of abstraction that you need a tool in the first place? Let me elaborate on what it took me to implement a CRUD controller. I had to implement a repository interface, a respository a context, a service interface, and a controller. Then I had to understand how to write the swagger documentation. Then there is a convention of wrapping every result and exception in some kind of wrapper, which is not documented so I had to figure this out from looking at other controllers. Then I saw a execution path for another CRUD controller which could throw an error which was not in this wrapper, so I had to discuss this with someone from the team. Sure enough, he is in another country, and takes a while to respond. I was lucky it was still morning, or he would have gone home already (there's a 4 hour time difference). Sure enough, this was a bug in the other controller. Then, there is a logging and a monitoring service I had to understand and implement. Undocumented, of course. The controller I used as a reference was inconsistent in monitoring, so I had to discuss this. Then, the requirements for the controller are not clear. The RESTful way of responding to a GET request for a nonexisting resource would be a 404, but the wrapper does not allow this. The reference controller returns 200 OK, but with a null value. So I had to check if this is indeed what's intended. Then I had to figure out how the unit testing framework works and I had to write tests for each method. OK, good practice, but it feels a bit weird, since the unit tests should not use the database while the entire purpose of the CRUD controller is to use the database. So much of the logic I'm supposed to test is mocked. So, I had to learn how the mocking framework works. Then I wanted to write unit tests for the repository, but entity framework crashes when I use an in-memory database. The other developers had a look, but didn't understand this either. The other repository implementations are not tested anyway, so I skipped this. Additionally, visual studio crashed, corrupted my git repository, and I ended up deleting and cloning the whole repo again. Then, I had to configure the project again before it would build, which involves opening the project in an older version of visual studio, then opening the same project in the latest version (some errors magically disappear), and adjusting the IIS settings (which are a mystery to me). I also had a long meeting to attend, and the person who's supposed to get me started didn't have time to help me. In the end, I'm still not quite happy with the actual logic in the controller (it has inconsistencies similar to the controller I used as a reference), but I refuse to spend more time on it.
- Sammi 9y ago
  Look, work is always pain. That's why they give you money for doing it. The real question is what kind of pain are you willing to endure and why are you willing to endure that pain? Is there a problem that you think needs solving, that you are willing to endure pain for?
- atoko 9y ago
  Most software is moving data around. All the abstractions you mentioned have a purpose. It makes sense to test each in isolation. For example, a controller whos’ service is a mocked implementation. You can test that your controller and its routes make the correct service calls without ever hitting a database. About the documentation, maybe you’re the one to take initiative and spin up a wiki? Maybe you’re the person that consolidates logging into a reusable internal library? Related to the topic, maybe this is not what you should be doing. There is good work out there, but as cliche as it sounds, you have to show passion for them to find you.
- marvin 9y ago
  Hope you won't get me wrong here; this sounds to me like the million details required to implement something properly, and certainly a task like the one you describe here would take a workday or two to implement properly. But it does also sound like there are some problematic inefficiencies in the way your company's software stack is set up. Common tasks like logging, caching and error handling should be abstracted away to a separate layer so that you get it for free whenever you implement a new service or endpoint. Don't know if this is old news to you, but check out e.g. [1]. This part about abstracting away rote work and optimizing a stack to be less maintenance-heavy is a learnable skill. The problematic part is that your working environment needs to have it in its culture. It needs to be okay for staff to spend a week here and there tuning a process that's used again and again. This is a big force multiplier which needs to be appreciated by management. I'm in an online banking company with an 18-year history and all the cruft that entails, and we're in aggregate spending multiple full-time positions continually upgrading our infrastructure and practices. Releases used to be one-week affairs that were performed twice a year. Now they're done in half an hour, most of which is verification and monitoring. Etc, etc. [1]: https://msdn.microsoft.com/en-us/library/dn223671(v=pandp.30).aspx https://msdn.microsoft.com/en-us/library/dn223671(v=pandp.30...

gurkendoktor 9y ago

I don't think this is the general frustration with programming that the grandfather post mentioned, it sounds more like you are working on a bad project. There's always been some push-back against over-abstraction, from Rails' "FU Java" spirit to the whole Go ecosystem. It's just that these jobs are much harder to find than the typical Java EE hellscape.

anonytrary 9y ago
I have seen some very over-engineered crap coming from GAFAM people, bringing such conventions to modern languages...

gambiting 9y ago

I have similarly started coding at around 12, and now I work as a C++ programmer in games....and love my job. On the other hand, I get paid peanuts compared to literally any other industry. But then all of my programmer friends who work in other industries(and frequently make 150-200% of what I make with the same level of experience) hate their jobs with passion, every time we meet it's just an endless rant on how the job is shit, the managers are idiots and customers don't know what they want. While I look forward to going to work in the morning and build stuff that gives me and others joy, and my managers are also cool. Is that worth dismissing for a higher salary? I don't know, I haven't decided yet.

cableshaft 9y ago
Game dev has it's own industry problems, not simply lower pay. You might be working on something you enjoy right now, but that's not necessarily always the case, and there are plenty of crap you have to deal with from clients, publishers, and the like. And the market is severely hit driven, so you could be working 6 months to 2+ years on a project only to see it land like a thud in the marketplace, possibly due to nothing more than a couple reviewers that clearly barely played your game before writing a scathing review, or you just picked a bad week and get completely overshadowed by other games. I worked on 7 games for three different companies, and all of those games failed to find and retain an audience, for various reasons. You spend 4 years of your life working on projects that may as well not have existed, except for your own personal development, and the industry starts to look less appealing. I'm working on software I have much less passion for right now, outside of the game industry, but at least it gets used on a daily basis by thousands of people (not always, I've worked on projects that have gotten binned because clients have backed out or contracts never got signed, or the lead developer quit and the manager decided to outsource the project, in this industry as well). And at least I'm getting paid quite a bit more than I would in the game industry.

commandlinefan 9y ago

> The only challenging aspect is the lack of conventions and documentation. Well, don't forget the challenge of coming up with new, creative answers to why isn't it done yet and why aren't you working faster and what do you mean "reading the documentation", just program, that's what you're paid to do!