Ask HN: How can I grow beyond being an engineer that just completes tasks?

[lostmyotheracct]

I’ve been given the feedback that I do an excellent job completing the tasks I’ve been given, but that I could grow further by identifying proactively identifying issues and proposing solutions.

It makes sense in theory and I really admire other engineers that are able to do this. But I really struggle with this. If I can identify problems at all, they often are low impact problems or I can’t think of a solution. For engineers that are good at this, what does your thought process look like?

[not_your_vase]

In my experience this works only if you are working on something that you are passionate about, or at least something that you use every day (not because you are forced to, but because you want to). That way, when you have some personal interest in it, it is kind of natural to recognize the shortcomings of the current state, and make improvements. If your current place doesn't offer such challenges, maybe it would worth thinking if there would be any other product that you'd prefer more working on.

Personally I could never make any meaningful improvement over any enterprise financial offering, but for example give me a personal music player to work on, and will make the best of it in the galaxy, even without any guidance...

[GianFabien]

In my experience it requires in-depth domain knowledge to sufficiently understand the environment in order to see problematic issues. Since the scope of your question depends on your environment and context, why not study those around you who do identify problems and propose solutions. I'm sure that if you asked some genuinely curiosity driven questions, you might get some useful insights.

[al_borland]

Not everything is going to be a massive problem. Build the muscle on some of those things you think are low impact. This builds the habit and some bigger things will jump out in time.

You also may not know the real impact until after you do it. I made some stupid little tool to help people parse/format text, because one or two people at the office would always ask me for help. I thought those two people might use it a few times per week. I was wrong. It was used by about 150 internal people, thousands of times per week. I saw people using it during their sprint demos to fix up text before doing whatever they were looking to demo. I even had people show it to me as something I might find useful, and I then had to tell them I was the one who wrote it.

In terms of thought process. I get frustrated by things I think are stupid and needlessly annoying/difficult. So when I see something I think is stupid or harder than it needs to be, I try to make it easier and less stupid. Little things can add up to make a big difference.

[austin-cheney]

Management is literally telling you that you lack initiative and/or originality. You are good at doing what you are told but nothing more.

You should spend some time AT WORK writing original software to solve a work related problem. Don’t expect there to be an agile story with your name on it. Do it only because you refuse to repeat the same stupid shit over and over.

Grab the bull by the balls and punch it in the face until complete. Nobody in their right mind will ever task you to grab a bull’s balls or punch it in the face but once you’ve finished you can do something nobody else can. That is literally the thought process: high creativity, low neuroticism, easily frustrated by repetitive nonsense.

[croo]

Think about what annoys you at your current workplace, what really pisses you off. That is a great indicator that you give a fuck about it and you can use that passion as a force to drive a change no one asked for but you.

[solardev]

I don't know what your role is, but in the web app frontend world at least, it's super helpful to work closely with the UX and support people, and where possible, with customers directly. You get to see how they use your app in the real world, what their pain points are, what features they're likely to need for any given use case, etc.

Over time you learn to anticipate patterns that will result in poor UX, you can identify them during design (hopefully) or coding (if need be) rather than after a customer complaint. You propose common-sense solutions to everyday problems because you've seen them before. You can fix them in various ways, both in design (learning from the UX people) and in code (seeing how it's done in other codebases, maybe UI libs and such).

If you're further removed from the end-user (backend, devops, etc.), it's harder to get an idea of what the public wants, but you still have internal "customers" – other devs. Is there some API endpoint that always takes a few seconds longer than it seems like it should? Or something that crashes once a week but just gets lazily reset? Those are opportunities for optimizations and debugging.

Bigger than that, is there something convoluted about your build pipeline or CI/CD? Your containers are always hell to maintain? The docs suck? Nothing scales? You're stuck on some old version of a proprietary database?

At the end of the day, all software is imperfect (and a lot it is way worse than that, especially on the web) and there are always opportunities for improvement.

But maybe the bigger question than the "what" is the "why". If you feel like you're just a cog in the wheel, completing tasks and slowly burning away points, it's just drudgery day in and day out. You have to find something you actually care about in your day-to-day work, or else no amount of ideation and problem-solving is going to feel good. It'll still just be drudgery.

Either you learn to love some aspect of the work by itself (maybe you become an expert in some particular part of the stack, and people in and out of work really start to respect your solutions and opinions), or in the particular field you work in (why are people drawn to your field? what were their dreams when they joined?), or the team you're on (what do your teammates love to work on, what do they hate, how can you help fill the gaps), etc.

Curiosity is something that can be encouraged, but not forced. You have to just keep trying enough different things until you stumble upon a "huh, that's interesting..." moment that really piques your interest. If you force yourself to sit down and look for boring things to improve, that's only going to burn you out. Maybe think about your own hobbies and dreams and ask "what would be REALLY cool to work on?". Maybe you can't jump right into that specific thing right away, but what moves can you make to bring you closer to it over time? If you can move in that direction, your work can get more and more interesting, and maybe one day you'll be in a situation where you'll think, "I can't believe I get paid for this".

If you're still early in your career, it may also just be a matter of accruing enough experience, both technical and interpersonal. Over time you learn to anticipate both common technical pitfalls (devs like to reinvent the wheel over and over to solve the same problems) and common user needs (for both external and internal stakeholders) and can better contribute to ideation and design because it's probably similar to something you've seen before.

Hang in there. You'll find something :)