Comment by XCabbage | Hacker News Reader

Comment by XCabbage | Hacker News Reader

Parent Full thread

When you say

> My understanding of how software is built surpasses any language specifics

do you mean that sure, you don't understand all the language specifics, but that's unimportant because you understand the high level? Or do you mean that you keep track in detail of developments in each of the five languages you've listed (to the level of detail of reading all their release notes and testing every new feature, knowing about the characteristics of all different flavours of index in SQL databases, and knowing best practices for managing state in React components, as suggested in the article)?

If the latter - if you truly have an encyclopaedic knowledge of every tool you use - then, well, congratulations, but I hope you realise that nearly all of us who work with a diverse array of technologies never achieve that mastery.

But if, on the other hand, you're casually conceding that you also don't have the low-level mastery of the tools you use that you would if you worked with only one of them every day, then... maybe you shouldn't be disdaining the author as a failure for failings that you also have?

As someone correctly understood - I consider myself an expert in 2 languages, and good enough in a bunch of others to various degrees (mostly because of not using for a long while), and confident enough that should I need to I can pick up where i left off with those. I also make a point to learn a new language with a mini project to go with it every couple of years. And yes, to use your examples, I am very aware of SQL variants between mySql, Postgres, Oracle and MSSql, I work with React daily and well, the same with Python, and I handle all of what is called devops these days on my own projects. I've been around the block a few times. But all this I don't consider special. These are tools I use daily across 3 major projects (another story). And I am absolutely sure there are many many like me and those with a much higher mastery of those tools than me. I am still learning every day and when that stops, I will too. Doing full stack does not have to mean you sacrifice proficiency. I actually love the context switching and sometimes will flip between front and backend just as a head-cleaner exercise.

As a side note: we're currently renovating our house and I love watching the builders work. They seem to be full stack in their abilities as well. Electrics, plumbing, structural work, plastering, decorating, building our kitchen, opening walls. It is amazing to watch them work. I asked the guy the same thing - where did you learn to do all this? how can you handle so much? His answer was the same as mine now - He's been doing it for many many years, and over those years those skills across all disciplines get stronger and fine tuned. This is just how it is I guess.

Not the parent, but I believe he says he considers himself an expert of two languages, and reasonbly proficient in five, not that he's an expert of all of it.

It's hard to know what people mean by expert without a defined benchmark of what an expert is. I would have previously considered myself an expert of one server side programming language, but actually I rarely read the C code, and never really cared about how the functions conformed to Big O notation; I have profilers and metrics and can worry about specifics as and when they present themselves as problems.

I can bootstrap a linux system, docker, kubernetes, CI/CD, secret store, provide monitoring and metrics solutions, and have guided several such systems through fairly strenuous security conformance. I've also did delivered some front end JS work previously. Knowing more than one area definetly has benefits but it doesn't preclude you from delving deeper into one of the areas.

Today I act as a consultant. I go big corps and teach them how modern dev works, and how to achieve this in a security concious and cost effective way. I get paid pretty well and I doubt I could do this if I was simply an expert in Java for example.

Edit: We live in a where most devs over 25 expect to be "senior" and can actually achieve this because most orgs are unwilling to pay for experience. Personally, I wouldn't sweat the labels too much.

What does being "senior" mean? I think it can entail many different things, from understanding the business, to work relationships with your stakeholders, to architectural expertise, and on and on. Compared to these, knowing the latest and greatest updates to any given programming language is fairly minor, especially when it's not the one you're working with at that given moment. You can catch up JIT when you approach a given problem on a given language instead.

There's no reason to think you came be senior in multiple languages. Even if they were unrelated and separate, you could do it, it would just take multiples of time. But the fact is, they are related. Concepts apply, and actually enhance when you apply them, across different paradigms. It doesn't work in a way that easily conveyed in passing comments (otherwise being a senior might be way easier!), but as you progress, your pattern matching brain will start to see and expect certain things from the languages you work with. That's what makes you am effective programmer in a language. The sense that "there has to be a better way to do this". Not knowing immediately what that way is.

When I hire, I never say "senior" or "junior". I don't care for those titles. They mean nothing. I meant "senior" in the "conventional" sense to match the language to that of the original post.

Likewise. Is it not still worth defining the inherent characteristics, even if it's not a job title?

Characteristics yes. As in what will one be doing during working hours, or what one delivers. However, I've seen "seniors" who really had no business being in software development. No idea how they claimed the "title". While at the same time I see what the industry labels as "Juniors" due to number of years in the job market, being so amazingly good at what they do that they put said seniors to shame. Yet the "business" needs those labels to justify a pay-grade of sorts. This is wrong in my opinion. Compensation should match the ability, not the number of years someone had the fortune of being employed at this or that capacity or how good they can blag through an interview.

You don't need to know all the details behind the types of SQL indexes. It is more important to know when to use an index.

You can look up the details then.

That's arguably true. But if it's what the parent comment meant, then it's illogical for him to deride another programmer as a failure for a post where he admits that working full-stack has led to him not internalising things like the details behind types of SQL indexes.

Reply on news.ycombinator.com