Ask HN: What else is there? | Hacker News Reader

Ask HN: What else is there?

6 pointstaway_12126 comments

I am not happy with how programming is done in my part of the industry (Java, Scala, some Big Data, some Docker, some web/Javascript). The work is usually organised in such a way to prevent one from reaching mastery of any specific part of the subsystem - team members are assigned tickets to work all over the system. This means that you spend a lot of the time in parts of codebase where you consider yourself merely a "tourist" and have neither incentive nor time to master it.

I believe that it's not accidental - the companies prefer to have swatches of replacable cogs producing mediocre-to-okish software vs having people who are masters of their respetive domains/subsystems, who can produce good quality product, but who also have lots of leverage when negotiating raises. It is most managers' dream to have a Ford factory level of organization and worker replaceability and in the projects I've worked on it's been pretty much realised.

I wonder if there are still parts of the industry where people are not just resources assigned tickets to work all over giant codebases? I'm thinking maybe small teams working on embedded software/device drivers or other areas where bugs are more costly. I do not know anything about those places though.

The situation you're describing sounds like the software is relatively mature. Maybe you can find a project that is in the early stages, where people are creating/owning the various subsystems.

Have you discussed the issue with your manager? If he isn't technical, maybe he's unaware of the product architecture, and sees it as one homogeneous blob. Try "I was thinking it would be more efficient if we could specialize in specific areas..." Then you'll have your answer.

I work at a startup, the CTO is extremely technical and I bet he's aware of the dynamics. I think I kind of agree that this policy is good for the company - currently, we're in an early "market grab" phase, so it's all about velocity (adding as many features as possible, we're selling to enterprise and for a lot of clients a lack of a specific feature is a no-go) and not so much about quality. The fallout of this approach will be burned out devs, but most of us aren't going to leave because it's pretty much the same thing in most other dev jobs. Hence my question - has anyone witnessed a workplace where mastery is possible and (preferably) even encouraged?

What you describe may not be uncommon for a junior level position, especially under a strong technical leader.

If you've demonstrated more senior skills, maybe you can discuss with him a more senior role. Or silently accept your role. You bet he's aware, but he may not be aware -- some highly technical people lack people skills.

From what I'm seeing, the most senior people are sadly all over the place as well. Because they know a lot about different subsystems, they're often pulled in to help on them (it's partially the consequence of aggresively growing the dev team - there's a lot of arcane knowledge required to be efficient and most folks are too new and don't have it). So, the seniors' jobs do not look fun at all. But yeah, maybe being a senior on a more stable team could be fun.

My $.02 - write/find/research security exploits and other bugs in your free time. If something feels too low level, try similar AppSec work in the stacks you're already "stuck" in (think: Java app logic errors, monitoring specifically for security, SQL injection, etc). Just find something to break and/or defend and do it. Note that defense is complex and each application deployed has plenty of edge cases to consider.

I'm kinda in your boat and I've been meaning to make this pivot myself for quite some time and know others who started out doing this long ago. So I can't really give the best advise about how to get hired in that industry -- I just know it's very possible.

You must not be doing scrum right if you feel about it that way

Reply on news.ycombinator.com