Hacker News new | past | comments | ask | show | jobs | submit login

> My last job title was Software Engineer II, but really I'm just a generalist that keeps failing upward, and I don't know whether if I were to double-down and specialize more, go deeper, or pivot out completely, I'd be able to do that well; it's a bit of a constant existential crisis.

As a generalist that still has the title Software Engineer after over 25 years of experience, I think I am able to empathize. I think, if you are a generalist and, like me, if you like "laying the pipes" to connect things end-to-end and see the satisfaction of having built the entire thing, embrace it. You should be proud that you can build a complete application though OS infra to database to backend services to frontend UIs and provide the glue of scripts as needed, all by yourself (not shitting on working in a team setting, just knowing that you could). I treat that as a badge of honor. Sure, I can't get super deep into one of these verticals, but then I'm a "builder" and I like the feeling it brings.




Well, I have and can do those things, and agree that those are very valuable skills to be proud of. I've just been kind of frontend only in team settings in a professional capacity lately, so it's something I'll be continuing to improve on.

Most of my work has been jumping into some crazy existing codebase and figuring out how to understand and contribute to it, so greenfield buildouts are just not something I've repped out, and think that's a bit of a weakness. As in, I can set up a database, build an API, wrangle a vps, and then build the front-end, but I don't really have much of a sense of how to do it quickly or by using decoupled cloud service providers, simply because I've never been in that position. Laying the pipes is sort of the essense of productive software engineering in my mind.

It is quite gratifying though to gradually be working my way to understanding how each layer of the hardware software stack work, and I'm starting to see those layers in real-world contexts, such as in getting a fault when compiling Swift, it'll show me the lower levels where the problem occured.


> Most of my work has been jumping into some crazy existing codebase and figuring out how to understand and contribute to it, so greenfield buildouts are just not something I've repped out, and think that's a bit of a weakness.

Without any context of the details of the work, one thing that has helped me is to lookout for scope of improvements beyond on the codebase itself. E.g. is there opportunity to provide a UI to the end-users of the code base. If so, since you have touched the codebase to contribute to it, your suggestion to work on those things to improve end-user's life may get accepted and then you have something relatively greenfield to work on. Doesn't always work out that way but sometimes it might. Another approach is building something on the side that you know will be very useful, even though nobody asked for it - helps you figure out the quick way of doing it (what you mentioned) since these are POCs and you can't repeatedly spend too long on them.


Really good suggestions, thanks. I suppose since I'm looking for work, it might not be a bad idea to do this externally as well, if any prospective companies' APIs are available, and use them as portfolio items.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: