Hacker News Reader

Comment by ahoka | Hacker News Reader

My gripe with most programmers that they keep re-learning the same narrow set of skills while ignore the rest that actually makes someone a efficient expert.

View on HN

It's surprisingly easy to have one year of experience despite working for ten years.

That one year is clearly more important than the other nine.

Not necessarily. I think at some companies you can just fall into local maximums.

For example maybe you've spent 10 years building the same CRUD front-ends over and over. You're probably really good at that. And the companies that you worked for needed that skill. However, you'd be a lot more marketable if you had other skills that you could put to use at future jobs.

That would be nice, but people keep hiring based upon specific programming languages and other programming specific skills.

Out of my last five positions, only two required a programming language I’ve already used before professionally. You just have to know enough to pass the screening and no competent interviewer will reject you based on lack of experience if you are a good fit otherwise. Hence the other skills, like basic soft skills, leadership, systems and ops knowledge and office politics matter more in the long run.

I mean, that's more information for companies than me. And yes, every job I've been made an offer for and accepted has been much, much looser on the exact languages or actually looked at my submitted code samples if they were interested in understanding if I could actually write code.

One of the worst examples was Amazon. They gave no indication ahead of time, but I was presented with a coding test with only a small subset of languages. My chosen language was F# because that's what I was most comfortable with but of course it was unsupported in their online tool. I solved a problem using discriminated unions, pattern matching, and pipelines. The interviewers were very confused, a bit antagonistic that I'd choose anything other than Java (even though no one told me ahead of time that there was a limited selection), and proceeded to show their lack of knowledge. For example, the interviewer kept bringing up a violation of the open-closed principle in my code. However, as I explained to them, that principle is only really applicable to object-oriented code. Since I was using a union data structure and pattern matching, that principle is not really applicable, as the functional approach is a transpose of sorts from the OOP approach. But I just got blank stares and an automatic deflation in the room of the interviewers communicating that they were ready for the interview to end. What was mind-blowing about it is that my resume lists nothing but functional oriented programming languages, with not a single example of Java, and I have plenty of code examples posted. But yet, I get asked some dumb question about reading a file using some terrible online coding platform.

You usually don't want work companies that do resume matching.

That is indeed true, but there is sometimes a mismatch in how a team hires versus how it actually works and performs. So sometimes, there are some missed opportunities to work in interesting places or fields just because their hiring process is uninspired.

I think learning some narrow skills is fine but the real issue comes when you don't deploy code to production. Because Production is the best place to learn actual problems.

I could expand that though to a much larger set than programmers!

I have the inverse problem, and it's why I don't have a tech job.

What do you think programmers ignore that would be beneficial?

Their working domain. If you're a developer in financial services, learn finance. If you're a developer in oil exploration, learn seismology. Don't constrict yourself to only being a programmer who writes whatever code you're told to. Be a holistic problem solver.

What's in it for me?

It's easier to write code when you understand the context. The customer requirements aren't always flawless and might make assumptions about things that you don't know.

During my career I've had to study:

  - electrical engineering (phase angles, current transformers etc)
  - finance (payroll and accounting)
  - building management (maintenance schedules etc)
  - mining (terminology, how explosives are set in underground and open mines)

I'm not an expert on any of those, but I know enough to be productive and know _why_ I'm doing the task I'm assigned.

Usually, a promotion from "one of the coding peons" to "the software architect who tells coding peons what to do"

Even if not an architect, it will make you a very senior and respected developer among the other smart people that can actually evaluate this. And if in your current company there are no such smart people, it will open the doors for you to find another company where those skills will be rewarded.

Understanding your users, and what you have to solve for, better than they can probably explain it to you. This makes both your and their lives easier.

To have more experiences and expand your horizon. You never know where it will take you next. Even if it does not translate to more money, it will definitely give you a sense of self-accomplishment and MAYBE make you wiser.

Maybe not needing to rewrite your code several times after being told that it's not what the client wanted to have?

People are down voting me, but I am really enjoying the answers.

Which would the rest be? Asking genuinely as a 4 YOE dev

Reply on news.ycombinator.com