Ask HN: I've realized I'm a bad software engineer and I'm over 30, what's next?
I'd been assigned a medium complexity task and I've failed to accomplish it, the code was all filled with hardcoded values, wrong structure, difficult to debug bugs and similar things.
I've realized I'm not a senior software engineer as I thought and now I don't know what to do next. If you read my resume it'll seem I am a senior but I don't really know where to place me in the "experience" spectrum. I've always managed to solve the problems in front of me but in a "hacky way" and now the issue was totally revealed to me.
I'm thinking about looking for semi senior roles but I'm afraid it'll look weird for the company interviewing me to hire a semi senior with +10 years of experience.
I've also thought about transitioning to a PM role but I'm not sure if I can be a PM if I'm not able to code things the right way myself.
A third option would be to take a break from work and try to learn to write good code but I'm not sure it's possible without working on a company with other people.
As you very probably see, I'm quite lost right now so I'd be very grateful if you can advise me what I could do next with my career.
274 comments
[ 3.2 ms ] story [ 283 ms ] threadI'm guessing that potentially you brought your smaller problem solving skills to a bigger task than you are accustomed to. If that is true it might simply be the case that if you were to have broken the large/medium task into a bunch of small tasks then you would have been a smashing success.
You don't need to know how to code the solution to be a good PM, it's a different set of skills.
QA - writing testcases, automated regression tests is also a possible path. Lots of companies want QA engineers that can write automated regresion tests (selenium etc)
No. QA automation code is still code. If a person can't write solid code, they're not going to succeed in QA doing automation either.
Hang tight. You can clearly learn to fix these issues and become better at building/architecting solutions. Spend some time reviewing projects on github and see how others have tackled the issues you are struggling with. Practice by creating your own projects. They don't need to be complete but will allow you to try different strategies for structure, hard coded values etc.
You could become a PM if you really wanted to... the PM's I work with have zero coding experience. This would be difficult for me as I don't see a PM as being creative and I like to build things.
You can do this!
That was my thought too. Programming is kind of like American Idol--a lot of programmers don't know how bad they are. The submitter said they failed to accomplish a medium complexity task, but it's not clear what this means: got stuck and gave up; missed a deadline; finished, but with poor quality?
From one of the submitter's thirty previous Ask HN submissions, I see experience working with a variety of tools, including machine learning. With batteries-included languages and powerful libraries, you can get pretty far in Tinkertoy mode, assembling the pieces of a solution. When you're faced with a task that demands more programming skill, it can be an adjustment.
If you have a passion for software development, self awareness, and a desire to improve, I think you'll be okay.
At least you recognise where the problems were - why not try and fix those problems in your next bit of work?
Start small. Like how to do a flavor of integration testing. Perhaps take some online courses? There is also a huge amount of YT vids out there.
One thing you may need to do is go back to the basics. Also make a task of it. Have a set time where you for 1 hour a day 'learn new coding skills'. Such as refactoring, code style and when and why to us it. Also find a project that you are interested in and follow it. I learn quite a bit doing this I have a dozen or so I follow and watch the pull requests to see interesting uses of code and style, even if I disagree with them. I do not contribute to them but I follow the style and commits they do. You can learn a lot by doing your own code reviews of other peoples code. Seeing how other do it and work on that.
Another option is to progress to team leadership. That role is more about listening to your team's good ideas and having good enough instincts to empower the good idea rather than you being a rock star developer yourself.
Alternatively you can just keep doing what you're doing but use this awareness you already have to continually up your game. Even the best of us are constantly learning.
2. You don't need to take a break. You can incrementally improve on the things that you know that you're doing wrong at your current job and improve while you're still there. Since you're already aware of a bunch of them, it shouldn't be too difficult to improve on them over time.
3. You may or may not be too self-critical. The way to find out is to prepare for interviews for a bit and then try out a few. Don't disqualify yourself, let other people do that.
Sounds like you've got a great opportunity to learn what you don't yet know: you already have a list of things you know you need to work on, a codebase, and a job. Do you think one or more of your co-workers would be willing to give you feedback? Would you be willing to take time (maybe extra time, 'off the clock') to practice?
If, e.g., hard-coding is where you're at, maybe something like working your way through 'Code Complete' would be of help, but I would pair the reading with doing, as close to the company's codebase and personnel as makes sense.
I've heard tell of people who asked to be shifted to a lower-level position so they could work at the level they were comfortable with.
A big part.
I suggest picking up a book on the subject, like "Code Complete" (at Amazon or wherever books are sold. Pretty sure it's at the library if you'd rather read it for free -- but it'll do better as a reference book on your desk for a few years). Use it and start practicing with personal projects hosted out of Github.
I also suggest using a daily practice like a code kata: http://codekata.com/
Another good one is The Pragmatic Programmer.
Lastly, this wiki is a gold mine of wisdom from hardened devs: http://wiki.c2.com/?StartingPoints
I really recommend you read lots and lots of those pages.
In a similar line of thinking to your Code Complete suggestion, a book like Architecture of Open Source Applications[1] might also be a good fit.
1 - http://aosabook.org/en/index.html
When you're talking about such a mentally heavy discipline, it helps to have certain behaviors happen effortlessly. You might otherwise learn these things over time with a large team, but I think certain brains needs this kind of practice.
Just like there are different ways of learning any subject, there are different ways of maintaining proficiency (IMHO).
that you can self-critique would indicate you potentially have a great future of leveling-up ahead of you.
The big question I would have for OP is 'do you want to do this anymore?'. I personally don't, I've loved development for 20 years but it's just not for me anymore, at least not for a day job. In that respect I'm in the same boat as OP, "What do I do now ?"
I get the feeling that quite a few engineers come at it from your kind of side. Only one dev, stuff needs to be done, it gets done with a lot of heaving and sweating.
Now you're in a larger place, there should be some breathing room. Find out how people do things:
- Maybe read the GoF patterns book to get some cookie-cutter solutions to common problems.
- A lot of the simpler DS&A learnings can be practiced with introductory leetcode problems. Don't sweat it too much, I'm sure there are a lot unuseful brainteasers there too.
- Get used to all the tooling around the code. Git, CI/CD. Build scripts.
When you get knocked off your horse you either give up or stand up. Maybe you are feeling it really hurt. But you’ve invested a lot in this industry and career, so don’t give up after your first real challenge. Get the fuck up and figure out how to deliver successfully on this project 1) what parts can you solve? Do those 2) for the parts you can’t, how can you? How do you break it down into specific problems? In this case, maybe one piece is centralizing hard coded variables into one place. What’s the best way to do that? Once you have specific questions, you’ll be able to find specific answers. Start working through them. If you can’t find self help, what about some colleagues you’ve amassed over 10 years? Worst case ask your manager, at some point you can’t bullshit things anymore, but give it an honest try first and outline what you were able to do and which problem(s) you are stuck on and what you tried already. Your manager will appreciate your ownership and your concrete ask for help.
Context: I made a career change and got fired from my first job 5 months in. It was devastating, but I got back up and got another job. I got a second job, went ok until i got a manager who said I was focused on the wrong things. After a year he kept complaining about it and in the end gave me a bad performance review. It left me shaken. I got back up and got a third job, where I am today, and I am crushing it. I still doubt myself, I still have wounds from before, and I even have doubts sometimes if I could succeed elsewhere, but I keep getting better, and getting up when I’m knocked off.
Good luck
The analogy that comes to mind is I've been playing basketball in my local town, and now I've gotten promoted to play in the big city. I now feel like a small fish in a big pond.
If you enjoy software engineering, I'd say, double down. Now that you're at the medium software company, seek mentorship and coaching from others.
In addition, there might be more homework (hitting the gym sort of), things you also have to do on your own.
It isn't going to feel good being humbled and I've been there myself. But if you think about the goal as "learning to get better" than "prove to others I am better", you'll have a better time walking through this challenge. This all comes from a person who is a PM.
So some tactical thoughts of possible advice: 1. Face the issues head on -> take all the negative feedback on the code and rework the medium complexity task 2. Learn to unlearn bad habits. Yes, it's harder, but it comes with practice. 3. Commit to maybe taking a course work online (maybe seek advice from others on what are good ones to address weaknesses you have)
Hope this helps.
BTW, you don't need to be able to code things the right way to be a PM. Coding is only one specific skill and not always necessary for a PM.
Agreed. My abilities as a developer increased tremendously at one of my jobs, and I can attribute 90% of that to a single person at that company who mentored me and helped me grow. (Hi, René, you probably don't read this.)
You can read all the articles and books you want, but actively pairing with someone on tasks and getting personalized feedback has a much greater pay-off.
Can share that experience as well, my first job there were 2 devs who were great programmers, highly educated. At every chance I tried to get as much knowledge from them as possible. They were happy to share and equally happy when they saw me improving.
makes me think how much I could have improved...
The `only` time I speak with my mentor is when I get stuck with a bug and need help getting started. I have asked frequently on how to do better code reviews or how did she get so good at programming - she always said it takes time. To get better with the code base - it takes time.
You can also find others on your team whose work you admire and ask them similar questions. Lots of people are happy to talk about their work when asked.
I guess in terms of concrete advice:
1. Put time on a calendar to work with this person; don't just slack back and forth about some specific issue for a bit.
2. If you're looking to become a better programmer, actually pair with them - take turns driving and writing code. If she's doing the driving, it would help to hear out her rationale for what she's doing - probably even before she starts writing. If you're driving, try to do the same.
3. Ask for code reviews on as many of your pull requests as she can provide; this is going to be pretty workplace specific, and is going to depend on how much code you end up putting up for review and how much time she has. It's a good way to get async feedback.
And yeah, it takes time and practice.
Moral of the story: find someone who's happy to mentor you, willing to pair program, and wants to see you grow and succeed. I can't promise that you'll never feel like a fraud again, but I can promise that you'll feel more confident about the work you do. The sooner you can do this, the sooner you'll find your "muchness" and become "much more muchier" (to quote Tim Burton's adaptation of the Mad Hatter).
I have also realized that there are some categories of problems that I really don't know how to solve well. So if I find myself struggling, I try to ask someone for ideas.
Just set your mind to doing better and in as little as a year it'll be a different story.
About the only
My manager has already been aware of my lack of knowledge but I'll talk to him to know if they still want me there. If I keep my job I for sure will be asking for more help at the start of a new project.
Either way. Keep your head up! Asking for help is the first step of an endless journey.
Some managers would welcome this discussion. It shows that you are aware that you have limitations and that you would like to improve. If nothing else it helps keep the manager / company from placing you on a task that you wouldn't be able to complete successfully, which would ultimately hit their bottom line. If the company / management are sufficiently enlightened (such companies do exist), they may be able to find additional training or development opportunities to enhance your skills
FWIW, when I was a manager, I ALWAYS liked to find things out before they created a problem, when there was time to fix them, rather than in the middle of some critical task.
Good luck!
* do nothing and keep quiet (almost always the wrong thing)
* say "help"
* say "I've found this specific problem, but I don't know what to do"
* say "I've found this specific problem, here are some options for fixing it - what do you think?"
* say ""I've found this specific problem, doing X will fix it - what do you think?"
This will vary a lot in practice and depending on circumstances, but I think as people increase in experience and knowledge they tend to approach management with solutions rather than just problems.
You should go to you manager with a look to the future: come with some specific things you can do differently on the next project, and perhaps also some general 'goals' for improving your skill.
Then, most importantly, do what you said, and get better.
All this assumes you are happy and want to stay in engineering, if you do think you'll be happier doing something else, then by all means go ahead and do that.
Why would you think they don't want you there? This is not a helpful mindset to have. Here are the facts:
1) You passed the interview process.
2) They made you an offer.
3) They've continued to invest in you as an engineer by giving you feedback on your weak spots and where you can improve.
If you were really that far behind, they would have realized that in the hiring process and you would /not/ have received an offer. So let's start there. They definitely still want you there. That is why they hired you.
Second, let's talk about your "lack of knowledge," "being behind some things" and "real world experience" that "slapped [you] in the face" -- based on your mindset it looks like you are viewing this as a negative, or as proof of failure. Why is that the case?
You have 10 years of experience solving problems and getting paid for it. Now, you are solving different kinds of problems, so you're developing new muscles. It's expected on their end (and should be expected on yours) that there is some kind of /ramp up/. Talk about what ramp up means. Figure out your manager's expectations, and figure out what resources you have available to engage in ramp up. I guarantee you this, there's ramp up at any new medium-big company anywhere you go. There's tribal knowledge, spinning up on the industry vertical, etc -- all of this is incompressible, doesn't matter how good of an engineer your are.
If your manager is any good, they likely know about this and will appreciate you being aware of this problem as a logistics problem, not a moral problem. So think about it that way. Stop thinking about "whether they want you there" -- start thinking about "what blockers are in your way towards being productive" and start building a game plan with your manager. Worst case scenario, you're not able to accomplish it, but at least you gave it an effort and approached it the right way. That's a much more mature, proactive and effective approach than self-sabotaging yourself with feelings of inadequacy. I have a hunch that you won't fail if you do this, though. Just thinking about what you want to get accomplished and the nitty gritty details of how you get there and collaborating with your manager to get to a plan you're both happy with is /a lot/ of work -- once you've done that, if you work at a functional organization, the chances of you succeeding are very high!
Give yourself a pat on the back, while you're at it. Getting to a point where you're still being challenged after 10 years of experience is a /good/ thing! It reflects well on you and indicates your desire for growth. In all likelihood, your company saw this motivation in you and that's why they hired you. Look at the positives and opportunities here, and I'm sure you'll do amazing.
Good luck!
Maybe the real issue here isn't engineering ability but communication, that you didn't let anyone know you were having challenges, didn't set expectations about how the project was going.
There could be more or less going on here than just code quality, so like I said, really listen and ask questions and keep an open mind.
Also to reiterate what others are saying, don't go asking about being fired because it can come off like you want to leave or have given up. You've been humbled but it doesn't take away the good parts of what you do, you're a pragmatic, independent, get stuff out the door type adjusting to a larger team. This is normal growing pains.
More generally, without having worked at a company that size yet, you can't be expected to come in with all the domain knowledge that dev team veterans have. Forget about titles like "senior" and what that means. Doing mostly-solo dev work for a long time is just a very different kind of work than writing code in a shared codebase with a team of coworkers of varying experience and skill levels. There will be aspects of maintainability and clarity which simply aren't a big concern in your solo projects but make a big difference when you have dozens or more developers working on the same code. Communication with coworkers becomes an important skill, collaborative project management etc. These are things which you can't just study and learn on your own, you ramp up on them over the course of working in that kind of environment. So yes, you might be pretty "junior" at some of these medium-sized-company aspects of software development, but that's fine and only to be expected at this stage. Keep at it, gain experience, level up by doing.
Have you seen a shortage in people who dress up their preferences as facts? Maybe a better question is, who is producing the good software? Oh, and software ought to include malware (personal preference).
Generally, good software would have to be first defined and there's no universal definition. In most projects, I require it to have the following properties: * New developers find it easy to ramp up on * A handle on the defect rate (usually through adoption of best-practices like unit tests, fuzzers, automated tools, CI/CD, reproducible builds, etc). * "Fires" infrequently enough relative to team size that it's manageable to accomplish your business goals. * No "surprises" in adding new features/fix bugs where you didn't expect them. * Meets business requirements today & can meet them tomorrow.
However, in other cases, like prototyping, "good software" means, "explores the problem space as quickly & cheaply as possible without worrying about any of those other things". Some of those other things can be useful in accomplishing this, especially if you plan to pivot from prototyping to the above definition. If you don't use them effectively then throw away your prototype before productionizing & start from scratch.
I'd also add to this: learn the why as well as the what. There are reasons why hardcoded values shouldn't be used, why OP's structure was bad, and so on. Learning why will help build those habits and make them stick.
Also, one needs time to get used to a new project, new environment, new colleagues, etc.
In every domain, the more you learn, the less you feel knowing about, and that's a good sign.
In this industry, the ones that make it, are the ones that keep on going forward.
First thing is work out to spin this properly - you're seeing this as a failure with hindsight, but why is it really like that? E.g: were the requirements firmly defined or were you trying to hit a moving target? Were you trying to appease too many owners? Were you lazy? Lack support? The most valuable thing you can provide is some objective context around why things are the way they are. Theres also different "software engineers". Maybe its the company type that you dns fit in well with? Rule number one: cut yourself some slack like you've probably given the other folk involved in the project.
I think this is definitely an option if you want to go for it. There might be some companies who will discriminate against you, but they'll definitely be some who won't. The key will be explaining to them (and convincing them) that the reason you're not as senior as one might expect is because you were never exposed to good practices or challenged to do better, rather than because you tried and failed to learn how to do things better. It sounds like this is genuinely the case, so I imagine it wouldn't be too hard to find people you can convince.
However:
> If you read my resume it'll seem I am a senior but I don't really know where to place me in the "experience" spectrum
To me it very much sounds like "junior". So it really depends if you are prepared to suck it up and learn everything afresh with an open mind. If you are, then I'd certainly be willing to hire you for a junior position (if I were interviewing you).
If you are bad at PM you can do mid-long term damage to a product which is not fixable like a problem in the code.
PM might have coding experience or not, it helps a lot if they do, but good PMs have a set of skills which are completely unrelated to being a software developer.
If you can spot your own code smells, you're doing fine. Otherwise, read up on how to do so. I recommend Code Complete.