4 ms·

That was my take too. With 40+ years experience in software development and system administration, I don't know what to make of someone with obviously limited e

That was my take too. With 40+ years experience in software development and system administration, I don't know what to make of someone with obviously limited experience expecting to get a "senior" title or to pick and choose what they will or will not work on -- based on the programming language involved. That the author tracked time spent in each language, worried about the meaningless job title, but then decided that maybe they aren't interested in e-commerce (Shopify's core business) shows a junior-level attitude. When I studied photography I wanted to use new lenses, cameras, flashes, light meters, film. My teacher, a professional photographer, told me one day that amateur photographers obsess about equipment. Professionals think about lighting and composition. That stuck with me. Junior programmers obsess over languages and tools. Senior programmers think about architecture, data structures, team cohesion, requirements, business value. I'm sympathetic to younger programmers who enter the job market faced with the stupid algorithm-oriented interviews, which are a kind of hazing ritual performed by people with such poor people skills and confidence in their own judgment that they fall back on pointless whiteboard tests that give the interview process the veneer of rational objectivity. Instead that kind of process just insures that everyone who gets hired has the same personality (or lack of). A lesson to take away from this experience: The interview and hiring process may look like a serious attempt to find the one perfect candidate for an amazing job. Actually larger companies tend to hire lots of people who look promising, ignoring their work experience and desired career path, and just sift out the people who don't fit or can't produce. That's not new either. I started my career as a junior, hired along with more than 50 other juniors, assigned two mentors and allowed to sink or swim. Three months later only 15 of that group were left. Later in my career I mostly got hired through word-of-mouth and referrals, sometimes I was the only candidate for a job that wasn't even advertised, and usually I didn't go through HR at all. If you're still going through a funnel to get a job you are almost by definition not senior. Note to the author: Almost every place I have worked in four decades, with a couple of horrible exceptions, let me run errands, take care of my kids, take as much PTO I needed, asked me to take time off if I was sick, and generally showed a lot of flexibility with what's called work-life balance. Only badly-managed groups and companies don't do that, and it's not a new thing. Given the ever-increasing demand for skilled programmers companies are forced to bend over backwards to attract and keep good people, so a manager who wants to keep their team will accommodate.

Osiris 5y ago
> Junior programmers obsess over languages and tools. Senior programmer think about architecture, data structures, team cohesion, requirements, business value. Well said. One of the big focus areas for me as a lead engineer is to get everyone to realize that planning (discussion, design, diagramming) are part of the engineering process. Writing the code is a lot easier when you've already planned out how it's going to work.
- gregjor 5y ago
  Not just part of the process, but almost always the most important parts of the process. Programming languages are almost incidental. I get that everyone has preferences and strengths, but deciding you will only work with React or Python or whatever is self-limiting. Stay in this business long enough and you will see everything come and go, you have to stay open to learning new things, and working with new people. Measure twice, cut once applies to programming too. Without a plan you're just thrashing, which gets frustrating pretty fast.
  - mars009 5y ago
bsder 5y ago
> but I felt the months ticking by and my frontend skills degrading. Like it or not, he isn't wrong about this, though. Web frontend stuff is like phone app coding ... it's a treadmill. And if you fall off for 18 months, it takes a LOT of effort to get back up to speed.
- gregjor 5y ago
  I do front- and back-end web development, I have done that almost exclusively for years. It's not that skills degrade, it's that the tools evolve and change quickly, and teams move from one shiny thing to the next much faster in the front-end domain than in other areas. Without meaning to come off as condescending or rude, if you call yourself a professional programmer and you need to put in a lot of effort to adapt to the next version of React, you aren't senior. Adapting to rapid change is part of the career, and the only difference with front-end work is the mostly self-inflicted churn. HTML, CSS, Javascript are not changing month-to-month. Web sites I wrote in PHP and jQuery ten years ago still work. The key to keeping up with change in the software business (and it's the same, maybe worse, in the system admin domain) is to understand the core technologies and principles, which haven't changed dramatically in decades. It's far more important to understand HTTP (relatively unchanged for more than two decades) and how web browsers render (which changes very slowly) than it is to memorize every detail of how React hooks work this month. Excessive focus on languages and tools and always adopting the latest new thing is a sign of poor management and lack of focus -- and especially not focusing on delivering a product and adding business value. That can happen anywhere from the CEO on down but in my experience it mainly happens at the programmer team level, because playing with the latest dot release of Ruby or React is more fun than addressing business requirements. As I'm by now fond of saying, no company ever had the requirement "We need 2,000 more lines of Javascript code by next month." Nor does any company have the requirement "We need to move to the version of React released last week." If that's what you're concentrating on you don't understand business requirements.

Osiris 5y ago

> Junior programmers obsess over languages and tools. Senior programmer think about architecture, data structures, team cohesion, requirements, business value. Well said. One of the big focus areas for me as a lead engineer is to get everyone to realize that planning (discussion, design, diagramming) are part of the engineering process. Writing the code is a lot easier when you've already planned out how it's going to work.

gregjor 5y ago
Not just part of the process, but almost always the most important parts of the process. Programming languages are almost incidental. I get that everyone has preferences and strengths, but deciding you will only work with React or Python or whatever is self-limiting. Stay in this business long enough and you will see everything come and go, you have to stay open to learning new things, and working with new people. Measure twice, cut once applies to programming too. Without a plan you're just thrashing, which gets frustrating pretty fast.
- mars009 5y ago

bsder 5y ago

> but I felt the months ticking by and my frontend skills degrading. Like it or not, he isn't wrong about this, though. Web frontend stuff is like phone app coding ... it's a treadmill. And if you fall off for 18 months, it takes a LOT of effort to get back up to speed.

gregjor 5y ago
I do front- and back-end web development, I have done that almost exclusively for years. It's not that skills degrade, it's that the tools evolve and change quickly, and teams move from one shiny thing to the next much faster in the front-end domain than in other areas. Without meaning to come off as condescending or rude, if you call yourself a professional programmer and you need to put in a lot of effort to adapt to the next version of React, you aren't senior. Adapting to rapid change is part of the career, and the only difference with front-end work is the mostly self-inflicted churn. HTML, CSS, Javascript are not changing month-to-month. Web sites I wrote in PHP and jQuery ten years ago still work. The key to keeping up with change in the software business (and it's the same, maybe worse, in the system admin domain) is to understand the core technologies and principles, which haven't changed dramatically in decades. It's far more important to understand HTTP (relatively unchanged for more than two decades) and how web browsers render (which changes very slowly) than it is to memorize every detail of how React hooks work this month. Excessive focus on languages and tools and always adopting the latest new thing is a sign of poor management and lack of focus -- and especially not focusing on delivering a product and adding business value. That can happen anywhere from the CEO on down but in my experience it mainly happens at the programmer team level, because playing with the latest dot release of Ruby or React is more fun than addressing business requirements. As I'm by now fond of saying, no company ever had the requirement "We need 2,000 more lines of Javascript code by next month." Nor does any company have the requirement "We need to move to the version of React released last week." If that's what you're concentrating on you don't understand business requirements.