Hacker News new | ask | show | jobs
by 0xedd 1464 days ago
As a code developer, there is no reason to not keep coding. You don't have to deal with infra or packaging/deployment. It sounds like bad management on your company's part. In the few large companies I've worked at, software architects, programmers and DevOps were responsible for the different parts of what you mentioned. The architect designs and directs the "engineers" (software/DevOps). For example, "Java guys, please read all config from env vars", as part of good microservice design. Naturally, the service implementation itself should be part of a larger whole; most likely multiple small microservices. And you, the coder, just follow the design. DevOps take care of infra, ci and cd according to the same design. Overlapping domains are discussed and brainstormed.

Having said that, you are wrong in thinking you can learn something that'll last more than 5 years. It's possible but the field isn't about doing the same thing for a long period of time. The job description is better put as "quick learning capability". Which you said yourself; you need to adapt as time goes on. That doesn't necessarily mean AWS. It means Java WebFlux, in your case. AWS and k8s are, each, huge huge topics. They can each employ a team. You shouldn't dive deep into it unless you want to change career paths. AWS to become a cloud architect or k8s to become whatever-cool-name-that-hat-has. You can't be top gun Java dev and cloud architect. It's too much. Select few gurus could exist that excelt in both. But it's simply too much information to keep up with and not a realistic job description/requirement.

Bottom line is you need to continue to adapt in your field of choice (Java or AWS or k8s) and turn your critical eye to your own company. Something there sounds off. The DevOps guy should be the one to tell you lambdas can be written in Java. And the vprnd should be the one to choose Java, seeing as most of the company already knows Java. The architect can give you guidelines how to design your implementation to be compatible to cloud architecture. And you can just learn a few basics about AWS lambdas to be able to debug.

Anyway, sounds like a midlife crisis. Hang in there. I got myself a sports car.

3 comments

> As a code developer ... You don't have to deal with infra or packaging/deployment

This is false (and wrong). As a software engineer, you must understand and own what you do end-to-end, including:

* how to write your code

* software/hardware that your code relies on (databases, k8s, aws, whatever)

* protocols your software uses for communication

* 3rd party libraries that your software depends on

* how to build and deploy your software and environment for it (bare metal, clouds, mobile app stores - whatever necessary)

* setup testing + write tests for all of the above

* setup monitoring + monitor all of the above

at any company, at any scale.

I can tell you I'm far less productive as a developer when I have to waste hours figuring out errors to do with AWS cloudformation or various managed service issues, or play/app store certificate expiring or what not. I have the necessary analytical skills to figure out stuff as I need to, but it's far more efficient to let others who are used to dealing with it all the time and seem (perversely) to enjoy what I would admittedly consider the unsexy part of maintaining software and ensuring its availability to customers. I'd even argue it requires (esp. for operating production systems) a different sort of mindset. Sounds ultimately like a debate about where the boundaries of specialisation should be. Some programmers are happy (and very productive) being extraordinarily specialised (knowing only a single language and working only on very particular components), others are used to wearing a very wide variety of hats, that even includes people and project management. I'd probably consider myself somewhere in the middle, but recently I've been painfully aware of spreading myself too thin trying to handle both feature development, CI/CD maintenance and DevOps-related tasks ensuring our cloud-based environments are deployed to and operate smoothly. On top of various other tech-lead/staff-engineer type responsibilities of course.
How can you write code if you don't know where and how it would be running? For me it's extremely uncomfortable to know that there are "they" who will do the "unsexy" "dirty" work to make _my_ code run.

> I've been painfully aware of spreading myself too thin trying to handle both feature development, CI/CD maintenance and DevOps-related tasks ensuring our cloud-based environments are deployed to and operate smoothly.

Reduce complexity.

I never said I don't know where and how it would be running - I just don't feel the need to spend time dealing with that layer of things most of the time.

As for reducing complexity, what are you suggesting exactly? Most of the actual complexity I have to deal with is in our codebase to build the core application (which can run almost anywhere), which is independent of any issues with CI/CD and DevOps/cloud deployment. They're not complex, they're just frustrating.

> Anyway, sounds like a midlife crisis. Hang in there. I got myself a sports car.

Getting an EV sports car is like being a kid again. But you can still commute in it. How great is that!

Thanks for this post, I'll be rereading it, may even point this to some guys I work with. I appreciate it.