54

I am in my mid-to-late 20’s and recently (~4 months) got my first real job as a software developer on a 6 month contract. I love this field and everything related to it, but my worst fear of “not being talented enough” is coming true.

For most projects, I’m paired with a much younger, very talented person. He will often write the majority of the code while I just document or test, or make minuscule changes. Things that would take me an hour or two, take him 15-30 minutes. I feel utterly useless, and fear it’s too late for me to enter the field despite schooling so long for it. Why would anyone ever want a near 30 year old over a fresh college grad who’s more skilled?

Any advice from someone who’s been in this position OR from someone on the opposite end would be greatly appreciated.

EDIT: Not sure the proper etiquette (if this should be an edit or a comment) but WOW! Just wanted to say thank you to everyone who replied, and all the advice! I may feel like I am getting old, but there is still much to learn. Thank you all again so much!

1
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – motosubatsu
    Oct 23 at 8:46

15 Answers 15

129

The fact that you can understand, document, and test what someone else has written is evidence that you are not unqualified. That can be more challenging than writing the code to begin with.

Use this as a learning experience and PRACTICE what you learn. Software development is just like any other skill, you get better at it by practicing it.

Some developers are just fast, that you are not that fast is not an indication that you are unqualified and I suspect you will get better with some time.

~4 months is a very short period of time. Set yourself some goals and start working toward them.

9
  • 87
    Also "writes code quickly" is not the only way a software developer can be good at their job. How fast the code is written doesn't always correlate to the getting the goal of the project accomplished.
    – ColleenV
    Oct 21 at 14:49
  • 9
    If it was a time difference of say 15-30 minutes vs 1-2 months I would be worried. I wouldn't be worried even if it was a ratio of 15-30 minutes vs 1-2 days. 1-2 weeks might still be ok. Solving things you've already done is completely different than doing things you have never done.
    – Nelson
    Oct 22 at 2:10
  • 29
    An anecdotal example: There was a datatype conversion JS error that wasn't fixed in 6 months. The symptom was incorrect sorting (lexicographically instead of numerically). It still took me 6 hours to figure it out, but now I can identify it in about 5 minutes. This sounds "simple", but it was buried under tons of business logic, and the error only showed up about 1% of the time. Very difficult to trace, but laughingly simple to fix (just cast as INT before the bad sorts for the specific datatypes that should be INT).
    – Nelson
    Oct 22 at 2:33
  • 8
    @ColleenV : Can't agree with you enough. A huge drag on my productivity is working with colleagues who are just amazing at producing code to fix a near-term problem, much faster than I'll ever be, but can't/won't communicate what they've done. It comes down to incentives -- they're lauded for being great at their job, which I support, but a big piece is missing. If you can't communicate, it will always limit your effectiveness Oct 22 at 18:15
  • 10
    @ColleenV Also "writes code quickly" does not always translate to "writes code well." Some people are fast and very good while others are just fast. The clock starts when they start coding and ends when the last PR is merged that fixes all the issues that code created... ;) I bet with that measure the "fast" coders don't seem so fast.
    – JeffC
    Oct 22 at 19:09
36

Why would anyone ever want a near 30 year old over a fresh college grad who’s more skilled?

Because you have other skills to bring to the table which people straight out of school haven't learned yet.

I had been in a completely different industry for 15 years, I was a subject matter expert and well respected in my field ... then I switched and became a junior software developer in my mid thirties, with only two years programming education under my belt. Compared to the other graduates, I had a decade more experience in being an effective team member, handling conflict, and managing my work-life balance. Because of my previous work experience, I had long since lost any shame I might have felt in asking questions about what I was doing or why I was doing it.

I recommend you make a habit of asking (polite) questions on PRs about why certain blocks of code have been written the way they have, you'll soon find which people can defend/explain their work and maybe even find someone who can coach or mentor you in learning more coding patterns. Once you have a couple of good patterns under your belt things will start to fall in place more easily.

As everyone else here has mentioned - don't compare yourself to how quickly you can or can't code. I feel slow, too. I also know I could easily explain or defend anything I've written if it were questioned in a PR because, I take the time to think about why I'm writing something a certain way. By the sound of it, you're already well on your way to being able to do that too.

26

Impostor Syndrome is common in the industry. Not everyone is equal in every aspect.

If your employer is OK with your performance, you are all good.

Impostor syndrome: feelings of inadequacy in the workplace, leading to the fear of being ‘found out’ as a fraud. Chronic self-doubt.

Impostor syndrome is a phenomenon that can leave anyone, in any industry, feeling like a fake —from factory floors to the C-suite. Programming and software development is far from an exception. In fact, developers are particularly prone to impostor syndrome.

Developer impostor syndrome sees both junior and senior developers dwelling on the knowledge and coding languages that they don’t know. They struggle to recognize their value, and negatively compare their skills against the skills of others.

from: Developer impostor syndrome: why you feel like a fake

Further reading at Wikipedia: https://en.wikipedia.org/wiki/Impostor_syndrome

@Joachim Sure:

You’re a developer Suffering from developer impostor syndrome can be debilitating, but it can help to remember that you’re not alone. It’s completely normal, and more widespread than you might realise.

Developers are in a role where they’re always learning because it’s impossible to know everything all the time. So, if you are willing to adapt and learn new skills, tech and languages as you need them, then you aren’t a fake. You’re a developer.

3
  • 1
    thank you for the linked reading, I had no idea it’s common in the field!
    – user130115
    Oct 21 at 21:47
  • 8
    Would you mind relaying the relevant information from the link to your post?
    – Joachim
    Oct 22 at 8:42
  • 1
    This highlights the importance of constant managerial feedback, affirming and adjusting. If your boss is of the persuasion that "If things are going great, I don't need to say anything," then it's a huge challenge not to give in to impostor syndrome. Oct 22 at 18:16
23

Speed is not a plus in programming, on its own. I could write a Java app pretty quickly, but I guarantee you it would be garbage (as I don't know much Java).

Honestly, it sounds like you're paired with this person for a reason. Lots of "young" developers are like this - super fast, eager to do things quickly. But, in my experience, they're also not careful. I want careful eyes on code that's written by these programmers! Otherwise we ship code that's buggy and hard to fix later. So, I'd pair a young eager programmer (a "rabbit") with someone who's going to take more care - often someone a bit older, in fact - someone who can be the "tortoise".

3
  • 1
    It's a plus, it's just not the most important one. At this stage in his career, understanding and correctness/thoroughness should be what he works on. Oct 22 at 5:30
  • 1
    +1 - there’s good reason why "extreme go horse" is not a realistic project management scheme (even if it is a widely adopted programming style!).
    – Pam
    Oct 22 at 15:05
  • Yes. I've worked with people who can write code a lot faster than I do, BUT I can then go through their code and often make it run an order of magnitude faster (in fields where performance is critical), using less memory and having fewer potential bugs. And I didn't get a degree, or work with computers, until my mid-30s.
    – jamesqf
    Oct 23 at 3:29
14

The reason the other guy is faster, is that he is successfully avoiding the two most time-consuming tasks in software development: testing and documentation.

1
  • 1
    Yeah, it is pretty easy to be quick in your work when you delegate two thirds of your responsibilities. I wonder if writing code is around 40% of you work as software developer.
    – Neil Meyer
    Oct 22 at 18:05
13

There's lots of good answers already, I've upvoted 3 of them. But there's one thing that isn't brought forward in the other answers:

often times he will write the majority of the code while I just document or test, making minuscule changes compared to him

Part of why he's faster is that he's done it before, he knows what to do. With experience you will become faster as well. But for that to happen you need to develop, which it seems you aren't doing. Grab the next task and start developing. Let the other developer document and test, he probably need practice doing those parts of development.

Initially it will be quite hard, and take longer than if you colleague did it. And you will have loads of questions, it will be annoying for both you and the other developer. But that's ok, it's all part of the learning process.

Without doing actual development you won't improve as much or as quickly, make sure to get your part of the development tasks.

9

Most of the previous answers are good, but I just want to add some experience as a 50-year-old that has decided to stay in software development rather than do management, etc.

Technology changes constantly and fast. If you want to work in (fairly) modern technology, you will come up against what is termed being a perpetual junior. You may be in a situation where you will know all about some technology (say, JavaServer Pages), but now most employers demand something else (say, Angular + Spring Boot). So you may working with a much younger colleague that learned the latter technology during training and you have to play catch-up. (Guess where that younger colleague will be in 5 or 10 years? That's right - same situation you are in now.)

So there are a few things that will help you if more experienced, which you should learn to leverage:

  • How to write performant, secure, error-resistant, and readable (easy-to-maintain) code (those should each be their own bullet point :-) ).
  • Some fundamental tech (e.g. HTML, CSS and HTTP) has not changed that much in the last 15 or 20 years, and you should gain experience with whatever is fundamental in your field and know (almost instinctively) what will work well and where problems might occur regardless of whatever framework lies over them.
  • You should learn how to learn, preferably fast and effectively. Naturally being curious helps. If you don't like constantly learning, rather find another career track...

To end with: I laugh at some of the things I've written even five years ago. The only way to gain experience is writing lots and lots of code. Neither your first nor your second project is going to be very good (Book: The Mythical Man-Month by Frederick Brooks).

4
  • 1
    Thanks for this, from another dinosaur. While I can run in circles around most juniors in my weapons of choice, Angular is one technology which I so far have decided to take a deep dive in at some point, and not to try to wing it in a quick "hello world" session. Aside from that, I found that all my experience with other things transfers very nicely to most new technologies. What you write is all true, but there were very few really groundshaking changes in the last decades (namely, IMO, native clients -> Web 1.0 and classical deployment -> containerization/cloud hyperscalers). The rest..
    – AnoE
    Oct 22 at 12:15
  • 1
    ... were mostly variations on a theme, easily caught up with on the sideline. Where we are still very significant is to teach the young heroes (and heroines...) about the seemingly old stuff which is very much still around. SQL Databases, security, but also just how to structure projects (be it microservices or OOP class designs...).
    – AnoE
    Oct 22 at 12:17
  • 1
    Html 4 vs html 5 is vastly different. There was a great move to semantically meaningful tags in html5. Css3 also introduced pseudo elements that gave us the functionality we used flash for built into the CSS engines. It is simply not true that those language have not changed over the years.
    – Neil Meyer
    Oct 22 at 17:38
  • 1
    @NeilMeyer I did write "not changed that much" :-) Meaning conceptually. Yeah, there's new (and useful!) additions. But analogously you also don't need to relearn English just because new words get added. Just see how it's used and start using away - or not, if it's not useful.
    – frIT
    Oct 24 at 18:12
7

You might want to test out several related fields. Focus on a niche:

I've had a colleague who...

  • ...was very fast, but not very precise. In case of disaster this was very effective
  • ...was quite slow, but I was sure that when he said it was good, it was. This created stability and was nice for important tasks.
  • ...was good in testing, manual, automation, the whole process. Over time, the projects get more stable and fewer bugs make it to production, so less time gets wasted on bugs.
  • ..spent less time coding and a little more figuring things out, gathering resources and information and doing prep work speeding the others up, removing a lot of noise.
  • ...started to spent more time on keeping an overview on projects, doing long term preparation. When major updates are needed, this person often had prepared a lot, making it easier.

All of the above are developers, just each with their own niche. That combination of developers is a very effective one, as they are a lot more stable, predictable and self-sufficient than a group of 'pure' developers.

Just keep an eye on what else you can do. Sure, coding is a significant part of your job, but i.e. someone who speaks both 'people ' and 'code' is also valuable. And if you like creating proper documentation, that might be worth its weight in gold when a new person joins your company, getting them up to speed quicker.

6

This sounds a lot like imposter syndrome.

Imposter syndrome can be defined as a collection of feelings of inadequacy that persist despite evident success. ‘Imposters’ suffer from chronic self-doubt and a sense of intellectual fraudulence that override any feelings of success or external proof of their competence.

https://hbr.org/2008/05/overcoming-imposter-syndrome

The fact that you've made it this far and that you have a job in this economy shows that you have skills. Just because someone is doing it "faster and better" doesn't mean squat. (Also, faster often means the opposite of better in software development. Especially when it's coming from a novice.) Even with my years of experience and wide range of experience, it took me 5 months to find a job recently. The job market right now is really competitive and the fact that someone wanted you for this job shows that you have the skills for it.

Instead of paying attention to "the other guy" and how fast they are, you might want to follow up on how many times their pull requests/commits/changes are rejected from code reviews and QA. You might also pay attention to how easy their stuff is to understand, how organized it is, how easy it is to update, and more on the quality side of things. Pay attention to how stressed they probably are to make the code changes quickly. You'll probably see their ability in a very different way.

That said, ignore them, unless you want to learn any actual good habits they may have. Ignore other people's productivity and only pay attention to their good habits to learn from. Everyone is learning and doing at their own rate. Some people simply type faster, some catch on to certain ideas faster, some people have vast amount of experience to handle things faster.

Everyone is faster than everyone else at some things, just like everyone is slower than everyone else at some other things.

You are not in competition with anyone but yourself.

Say it out loud if you have to.

If your boss pits developers against each other, that's a bad style of management and should be avoided. If you get fired for this reason, feel lucky you can now find a better position. It won't feel lucky, that's for sure. I've been job loss enough to understand, but software development is a team sport, not an individual one. Your team should be helping each other with learning, understanding, teaching, unblocking, and more. There are times when competition can be healthy, but it's more often used detrimentally than not.

BTW, making "miniscule changes" is often harder than writing large swaths of code. It's pretty easy to throw down 100-200 lines or more of code, but going back through and fixing anything that doesn't make sense afterwards, now that it's all typed out, because the logic/assumptions of it changed as it was written is much harder.

Documentation is also really difficult for most programmers. I know I hate it. You have to actually come up with an English (or whatever spoken language is necessary) explanation for what the code says. I mean, "it's all right there, can't you understand that? The code says it all!" Seriously, though, trying to make sense of someone else's code is a skill that takes time to develop. If you already have that, you're ahead of lots of people in this industry. Too many times, the documentation is just more code and assumptions for users, managers, and sometimes other programmers to not understand. If you are writing the documentation so others can understand it, you're doing a really good and important job. I understand it's not what you want to be doing and don't want to get siloed into always doing it, but it's one more tool in your toolbelt to be proud of.

And no, I don't think you should let yourself be siloed into just making documents or small changes, especially if you don't like it. I've been siloed many times and even when I'm good at it or like it, it still gets boring after a while. I like to change things up a bit just to keep things interesting.

I was in my early 30's before I got my first programming job and now I've been doing it for almost a decade. I started learning programming 28 years ago, so finally getting a job using it as a primary function ~18 years later wasn't my ideal situation. I've worked for programmers that are younger than me and now I'm working with developers older than me. Sometimes I'm faster and know more than them, sometimes I'm slower and don't know as much. The fact is that I'm still learning. I've used around 40 different languages, libraries, frameworks, and more, yet I don't know everything. I still struggle with some tasks while I breeze through others. You will too throughout your entire career. That's just the nature of things, regardless of industry you're in, unless you are so underemployed and under utilized that you don't even have to think about your job to do it and are miserably bored with it. I've been there and done that, too.

My point is, again, that you shouldn't be comparing yourself to others unless it's to learn good habits and skills from them. Programming isn't a race. It's not a game to see who can get the most points. Programming is about making the best product you can, and that involves serious thought, teamwork, and writing the best code you can. And that all takes time and effort, not speeding through tasks as fast as you can. So you not being as fast as someone else makes little difference in the grand scheme of things.

1
  • 2
    Glad you pointed these things out. Just because the younger programmer is whipping out code in a third of the time does NOT mean it is either good or complete. If the OP is testing, is the younger person also testing his code? If the OP is documenting the code, is the younger person also documenting his code? It sounds like the answers are a resounding NO. Untested and undocumented code is not complete.
    – CGCampbell
    Oct 22 at 15:40
3

Considering your skills, I suggest you look into QA Automation as a career path.

It seems more suited to your skillset and will make you feel less frustration.

1
  • The advice is actually not that bad. E.g. in the last years, the so-called "functional safety" is more and more arising while QA/QS is kind of a more broad field.
    – Ben
    Oct 25 at 6:52
3

This seems like the kind of false belief that might yield to piling on, so yet another answer...

I am a staff engineer (1 level above senior) for a Fortune 50 company, i.e. I'm a pretty darn good software engineer. I am roughly at or above the level of most of my peers in my (rather large) org in terms of skill.

But I have a couple of friends...

"Bob" is a Principle Engineer who I met through a mutual hobby and whose professional bio includes tidbits like "contributed the driver for x file system to the Linux kernel" and "used to work for Ian Murdoch" (of Debian Linux fame) and "wrote a production C compiler for such-and-such architecture". Bob is currently the head Java guy at $HOUSEHOLD_NAME_COMPANY. Bob is only a few years older than me and has attained professional success I am unlikely to match.

"Greg" I coached in sports when he was a teenager and encouraged to take up programming. Greg graduated with a double major in math and CS from a well-known program and was heavily recruited for an internship and then a job at $OTHER_HOUSEHOLD_NAME_COMPANY in NYC as a data scientist and probably made more money in first year as an engineer than I did in my first 3-4. Greg is noticeably, quantifiably more intelligent than I am and has had greater success despite being less than half my age.

"Pam" is another person I coached in sports, graduated from the same college as Greg, did a masters in CS at another respectable school, followed by her internship and then job at $YET_ANOTHER_HOUSEHOLD_NAME_COMPANY in a town in California that rhymes with "Fountain Dew". Ditto on the being noticeably smarter and more successful than me.

If I set my bar for success at "beating" those people I am going to have a no good very bad not happy time. I'm not saying that competition and being the best doesn't matter, but this is a field where even the bottom feeders are largely brilliant and successful (on an absolute scale). Are you sure that junior hire is the right point of comparison for you? I could beat myself up all day about never equaling my friends, but to what end?

And this applies recursively. Should the "lower ranking" engineers on my team (also brilliant and likely destined for great things) beat themselves up for not being on my level yet?

The demand for engineers far exceeds the supply, and his success in no way diminishes your chances. Cheer him on, then go do your own thing: there's plenty of room in this particular pool and the water is fine. There's always somebody better than you.

2
  • 1
    This really puts things in a perspective i wasn’t able to see. Thank you for your reply, it means a lot to me
    – user130115
    Oct 25 at 20:41
  • @bocorwen I was hoping that would be the case. I went through my own bout of weirdness by staying at my first employer too long and then when I was finally ready to leave I realized I had no idea of how good I was or wasn't. One extra piece of advice I'd give you then is once you're 2-3 years in make sure to keep your LinkedIn profile up-to-date and visible. It can be helpful for boosting your ego to have recruiters bang on your door. Oct 25 at 22:04
1

I would suggest you have a conversation with your coworker. I would start by saying you want to learn from him... how he approaches problems, how to be more efficient, how to be a better programmer, etc.

Do you do code reviews? If not, talk with him about starting. Even if it's only you two reviewing each others' code, it can be a great learning process for both of you. Include any automated tests in the code reviews. If for some reason you can't do code reviews, spend some time reviewing code he's checked in and try to learn from it. Ask him questions about what this code does, why he approached the problem in this way, or did he consider X approach instead of the one he took, etc.

While it isn't a "code" review, review each others' documentation. Maybe come up with some standards that you both plan to follow if there aren't any existing standards.

You might also try pair programming. When you are "driving", try to talk out loud about what you are thinking about, what your approach is going to be, what problems you foresee, etc. Encourage your coworker to do the same while he's driving. I think it will be a good learning, mentoring experience for both of you.

Also talk to him about rotating duties. Make sure you get your chance to write code. You aren't going to improve if you aren't doing it on a regular basis. This sprint you start with coding and he starts on documentation. Whoever gets done first starts on writing tests, etc. until everything is done. Next sprint rotate where you and he start.

The end goal is for both of you to be better at all aspects of programming. You will probably learn a lot from him and he will very likely learn some things from you. Be willing to share whatever you can to make him more successful and I think he will have the same attitude with you.

1

The reason the other guy is faster, is that he is successfully avoiding the two most time-consuming tasks in development: testing and documentation.

0

When I entered the industry I just finished my PhD for which I had to program a lot, and I mean a lot. Moreover, it was never pure software but technically-scientifically related so I also had to pay attention to the consequences of the code and what information from data means, and so on.

My first working position was very close to someone who entered the company half a year before me with "only" a Bachelor. And he invested his entire life energy into this job, while me, after Master and PhD and thus, some years older, wasn't able to tune up to keep on speed with this guy. So I totally understand but, lucky me, after some months I figured out my strengths over him: 1) Experience 2) Speed is definitely not everything 3) Better understanding and even knowing the necessity of (programming/scientific) concepts and ideas which he totally missed as he, in return, lacked a Master and PhD and actually 4) being critically about what I do and what about others do.

He was mostly like "I solved this and that yesterday, give me a new task" while I was more like "Yeah, but does it make sense? Are there aspects which should be taken care of and paid more attention to and even discussed in a group?". The latter mentality improves the mentality and products of a company much more than just delivering stuff fast.

Products which are reliable and well-tested are more worthy than products fastly done. Sure, on the one side you have to release things fast so money is earned but when you do it too fast it might be much too effortful to change things and lastly this will be much more expensive than doing things slower in the first place.

11
  • 1
    While there's definitely lots of merit to thinking things through, there's something to be said against over thinking and trying to get 100% accuracy when that's not realistic. We definitely need to put lots of thought into software so we don't have to revisit it all the time for bugs and edge cases, but I've known several devs that take it way too far. Oct 22 at 14:52
  • I'm not sure on which "side" you're arguing but I would say it depends on what the software has to do. Is it a game or does it control a respirator? In the case of the latter better have someone who thinks over it multiple times...
    – Ben
    Oct 25 at 6:50
  • 1
    I haven't worked on medical equipment before, but I've known devs that want to take a week to ponder the 110% of edge cases and unlikely scenarios of even the most basic feature for days and weeks. They try to turn a 30 min code change into a multi-day project. That might make sense if someone's life depends on it or the feature continually has problems, but the other 99% of the time, it's just a waste of time. I've seen people take non-programming projects take 6-12 months to plan and design something I could have built in a day. There's limits to how much thought can go into something. Oct 25 at 15:00
  • I got your point that's why I pointed out the purpose of the software. It seems that you're from a "pure" software field. Maybe check out embedded systems where the code review and quality aspect is by far the most extensive aspect. I would even say, always when software results in real-world actions like moving mechanics or controlling other devices then you really, really, really need to pay attention to your code. But also not only when electro-mechanical devices are connected to it. Just have software for bank transfers in mind. I bet they check the code thoroughly ^^
    – Ben
    Oct 25 at 15:19
  • 1
    I come from a farming background, moved to computer repair for my first "career", and have been in software for only 9 years. I've DIYed for ~40 years, even building my own CNC machines and using Arduinos for robotics. I'm not from a "pure" anything. I do what's needed to get stuff accomplished. If that requires 2 weeks of research and thought before acting, that's what I do. If I can "git'r done" and have +90% of all use cases and 99.9% of likely use cases covered in a couple of hours, that's what I'll do. Oct 25 at 15:29
0

I think that a part of the imposter syndrome has to do with the fact that in tech you almost never know how to do anything, but you can always find out. This is a rather unique trait of this profession. In my life as a music teacher I almost never had to do with any questions I did not know the answer for already. Each grade had 10 - 20 competencies that a candidate had to conquer. Most of the effort was just building the ability to explain the work to different types of people.

I was recently asked by a person if I could format a laptop for him. I had a general idea how to do it. Get the OS iso booted on a thumb drive. Go into BIOS boot from the thumb drive and install, but then I realised after a while the stiffy is not getting picked up, why? Because you have to enable legacy mode.

Then I realised I was in what is called an infinite boot cycle, one Google search later I realised if you remove the stiffy when the OS gives you 10 seconds before the reboot then it defaults back to the hd and the OS install continues as normal.

Did I know how to do this? Not really, did I find out, yes I did. Now I have this real skill of being able to format a PC. Is this something that can get me paid? Idk, but I can do it now.

You must log in to answer this question.