Hacker News Reader

Comment by martamorena234 | Hacker News Reader

> For the first 6 months you're paying a sr. engineers salary to get jr. engineer productivity.

Then you are doing something wrong or have a watered down notion of "senior engineer" (as in "junior engineer" that spent X years on the job, as opposed to someone who is actually progressing well through his career in that time). Senior engineers should IMMEDIATELY outperform junior engineers. Knowledge of the system is largely unnecessary. What senior engineers bring to the table are completely different skills than junior engineers. You can have 100 junior engineers and they will still not be able to figure out the things a good senior engineer will do for you.

Probably you are not utilizing them correctly or giving them the right problems to solve.

View on HN

I'm using the definition of someone who has been professionally developing software for 10+ years.

So I'm comparing someone who has been professionally developed software on a different stack for 10 years compared to someone who has developed software on an identical stack to yours for 1-2 years.

There are engineers with 10 times one year of experience and others with ten years of experience.

Believe me they are very different.

I've heard this trope for the past 10 years. And just like different sr. devs are better or worse jr. devs can be better or worse. Ideally you always want to hire better.

If you ever need heart surgery, do you want the surgeon who has done 10 years of heart surgery (or better yet, 30 years)?

Or do you want the surgeon who has jumped from area to area and has no more than a year or two of experience in each area? The experience doing knee replacements will be invaluable in your heart surgery. Right?

It is so weird that this meme of "10 times one year of experience" is somehow become a negative.

Yes six months seems very long I recall when I switched to a new language (PL1/G) on the Map Reduce part of our project, the developer I took over from after 3 days said "you don't know it all yet"

I was teaching my self from a 1964 vintage IBM manual that my father had kept :-)

It's not just a new language(C#), it's also a new ORM (EF Core), a new front end (React or Angular or Razor or Blazor or whatever), a new database(SQL Server), a new cloud provider(Azure), a new web framework(ASP.Net), a new work tracker(Azure Devops)

That's a lot to learn.

You aren't wrong that it is a bit of work. It's just less work than learning the actual software itself by a lot. Learning .NET's flavor of the year framework stack is not that bad since there is lots of good documentation, classes, books, and blogs. Your software, at best, has documentation that is as good as .NET's. This is highly unlikely though. Learning the product's layout and quirks dwarfs learning the latest incarnation of .NET.

It can be, but a senior who is well-versed in the fundamentals and has some exposure to complimentary tools in other ecosystems is not going to have a problem coming up to speed with those tools.

What they're going to spend more time on is: learning how you decided to solve your problems with your knowledge of those tools and how you decided to fit it all together.

That in combination with the learning curve of all the tech can make the ramp up much longer than might be acceptable.

If you have been around for a sufficient number of tech cycles you already have conceptually analogous systems in your head, which you just have to remap to the new syntax. That's what makes a "senior".

The frontends are actually the hardest to stick with because they turn over fastest, probably followed by distributed-compute solutions. C# is a short walk from Java, SQL has been around for decades(even given dialect differences that change best practice).

Reply on news.ycombinator.com