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 ...
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 ...
27
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, ...
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 ...
15
You have a management problem. And, whether it is true or not, you should explain to them that the time he is spending testing is the reason the code is so good, and since he is still faster than other people, they have two choices:
Leave him alone, and hope to keep him for a few years before he figures out his worth and goes where he'll get decent pay.
...
15
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.
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 ...
10
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 ...
8
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 ...
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-...
5
If you want to work with and progress with Technology X, I'd say the best way to go about that is to look for and accept a position that specifically works with that technology. The second best option is to try and latch on to a company that is heavily and strategically invested in that technology as part of what they do, even through a different position, ...
5
There's quite a bit going on here, and not much of it good.
You hired a junior software developer who seems to be, overall, doing very well. That's a good start. However, juniors need mentoring to learn and develop their skills. So you've taken a junior developer, who may not have a lot of knowledge and experience in good manual testing techniques, and are ...
4
This is really simple. There's nothing wrong with the actual performance of this young developer. The problem is his performance measured by some rather stupid performance metric. So you just explain to him what he needs to do to get around that performance metrics.
I had the problem once where someone counted how often you checked in stuff into Perforce. So ...
4
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&...
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.
2
What leads to a collaborative software development workplace?
The need to collaborate. It makes no difference if it's a startup or not.
Businesses tend to be more focused on production, they have time constraints that directly affect their revenue stream or issues with staff retention, task tracking or a number of other things that do not affect academia as ...
2
I'm currently working (as software engineer) in an academia-based workplace and have previously worked for a mid-sized company. In the commercial company we collaborated a lot, while in my current job I'm mostly working on my own. The difference is the type of projects.
The commercial company was very focused on a certain area, so naturally we developed ...
2
Collaboration is driven by a need for collaboration, bottom line. In academia, collaboration often manifests itself in mentor-mentee relationships or in co-writing papers. In software, collaboration manifests in terms of large projects and separation of responsibilities, but also in mentor-mentee relationships.
If you, as an academic, want to have more ...
2
Job hopping won't be an issue if your CV is clear about which roles were permanent versus contract. There is far less expectation of longevity for contractors. You may wish to guard against any perception that you kept getting fired from contracts by explicitly stating "Short term contracts" on that section of your CV.
By highlighting that 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.
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 ...
1
I should have asked more questions about this before joining
That appears to be the obvious answer to your question. You need to ask in the interview about things that are important to you. Something like
How many of your products and projects are using X ?
What tool chain do you use for X?
What technology stacks are you using and what's the outlook for X
...
1
The size of the project leads to collaboration. Thus, the Large Hadron Collider has thousands of people from academia working together. Numerous space projects have an academic as lead scientist with hundreds of other people spread around the world collaborating. These projects often take decades with multiple rounds of proposals, redesigning, and finally ...
Only top voted, non community-wiki answers of a minimum length are eligible