Live data from Hacker News

Don't Call Yourself a Programmer, and Other Career Advice (2011)

kalzumeus.com

221–230 of 316 posts

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#221

Earlier quoted context omitted.

Agreed. The job doesn’t exist to train you.

It’s more nuanced than that. Most job reqs have “must haves” and “nice to haves”. My current job had one must have - C#/MVC/Web API and some Javascript experience - their current tech stack. Nice to haves were React, the fiddly bits of AWS, and Python. I was immediately useful because I was strong in the must haves, had a little AWS experience, and knew nothing about Python or React. I’ve since leveled up on the nice…

I find React's relatively simple architecture makes it easy to get into for JS devs; I've always found it extremely productive and maintainable. My sickness is to the point that it’s hard for me to imagine an immediate future where it hasn’t entirely consumed the front-end web environment like jQuery did 15 or so years ago. Maybe you're onto something, but I'm loving the new digs so far.

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#222

Earlier quoted context omitted.

There is a difference between “knowing it exists” and knowing what it can do. No, despite what a bunch of old school netops guys who watched an ACloudGuru video and now can click around and duplicate their on prem infrastructure on AWS (and cost more) think, it’s much more than just hosting VMs. And you kind of proved my point.... If you don’t know the wheel exists, you don’t know you’re reinventing it.

Look, I don't even know what your point is. I thought you were claiming "you can't/shouldn't hire someone who doesn't know well the technologies that you currently use". If it's not that, then don't mind me, I was debating something else/ I misunderstood your point.

That’s exactly what I’m saying, in my example the old school netops guys who didn’t know anything about the “tech stack” in this case AWS, ended up designing horrible, inefficient solutions because they were learning on the job. They could have been “senior network engineers” because they spent years managing a colo. But, they definitely weren’t as efficient as someone who had built real world solutions on AWS.

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#223
post #58

Earlier quoted context omitted.

Profit centers consist of people who can directly attribute revenues or savings to the work that they do. Everyone else is a cost center. No, it's not fair.

The bullshit is hidden in the word "directly". You can define this word to mean whatever you'd like to mean. You can say a salesperson directly adds revenue to the company, but it's not really directly, the billing department is much closer to the actual money. You allow yourself to take the billing department for granted, but that's just because you don't work for the billing department. In the same way you could vi…

Profit center: spending more money on it can make you more money. Cost center: spending more money will not be able to increase your revenue, hence the only way to improve your bottom line is by reducing costs.

A lot of the confusion on this thread was conflating necessary functions with profit centers. Billing and compliance are both necessary. Done poorly they can cost a lot of money. Done perfectly they can never increase the actual income of t he company. That is why sale and product development are traditionally the only parts of the business identified as profit centers. It doesn’t mean the others aren’t important just that they have different goals. Profit centers look to expand the business while cost centers look to increase efficiency through optimization.

They have different value during the life of a company. During growth, profit centers are the most valuable source of effort while for a mature company that has saturated its market cost centers are most valuable to focus on. The advice to stick to profit centers is somewhat equivalent to sticking to growth which nearly always has a higher return than optimization.

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#224

Earlier quoted context omitted.

I’ve met many programmers/engineers who are terrified of becoming management and make (what I believe to be) poor career choices trying to avoid it. Instead they get passed over for pay raises and interesting opportunities because they’re seen as being difficult to work with. When times get lean, I’ve seen those people get laid off first because no one likes working with them. I work on a team of 50 employees. For th…

If only we could retroactively demote all the managers who suck at it!

If you're at a healthy organization, they support managers transitioning back into engineering.

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#225

Earlier quoted context omitted.

>In web development, losing a connection is a failure case. That's changing with the advent of progressive web apps. It's possible to write web apps now that are robust in the face of network problems, e.g., the web app renders and is functional even without a connection.

I’m not questioning whether you can do it with web technology. But you still have to design it where both your business logic and your data can live on the device and it can queue submitted data until there is a connection available and if multiple people are updating the same record, knowing how to merge the information or knowing which one takes precedence. I’ve even seen cases where the logic depended not on just…

You frequently encounter similar issues between multiple web servers. Either due to scaling to multiple data centers or when multiple independent services all update the same information. This can get really complex when clients start talking to multiple different services.

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#226
post #41

> Do Java programmers make more money than .NET programmers? Anyone describing themselves as either a Java programmer or .NET programmer has already lost, because a) they’re a programmer (you’re not, see above) and b) they’re making themselves non-hireable for most programming jobs. In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t be…

Stack is relevant though. If you need a front-end architect, and you hire someone with 10+ years Java experience, they aren't going to know the first thing about web accessibility, polyfills, bundlers, cross-browser support, etc. The domains of implementing microservices vs. writing front end code are fundamentally driven by very different problems. The stack an engineer has experience with can be one indicator of th…

Is this the right way to hire? Not saying it’s wrong but I’ve taken a different approach which has generally worked out.

Even if I was hiring for a specific role (front end), I care less about familiarity with specific bundlers or frameworks and something more like - “Can this person problem solve and deal with varying levels of ambiguity? Do they seem capable of figuring something out without a ton of direction?”

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#227
post #41

> Do Java programmers make more money than .NET programmers? Anyone describing themselves as either a Java programmer or .NET programmer has already lost, because a) they’re a programmer (you’re not, see above) and b) they’re making themselves non-hireable for most programming jobs. In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t be…

Stack is relevant though. If you need a front-end architect, and you hire someone with 10+ years Java experience, they aren't going to know the first thing about web accessibility, polyfills, bundlers, cross-browser support, etc. The domains of implementing microservices vs. writing front end code are fundamentally driven by very different problems. The stack an engineer has experience with can be one indicator of th…

I think what he is saying is, if you are hiring a React developer, but someone only has experience in Vue, would you not hire them because of their lack of React experience?

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#228

This article is to me quite brilliant and hits most of the right spots. I liked it. Then I see the picture of the author and cannot help but think: practice what you preach. I would not be caught dead wearing a red tracksuit on a bad hair day when posting a blog post about, among other things, how grooming well and wearing a suit helps you make more money.

The bias goes the other way now. A lot of people with a lot of money wouldn't hire a tech consultant in a "phony" suit with a stock photo -based website. They prefer "authentic" people who focus on their work, not their clothes.

I guess it kinda depends. Usually engineers do not get hired by 'someone with a lot of money'. They get hired by mid-level managers or a committee of stakeholders. I can understand that some scaleups in social media where hoodies are part of the corporate image are like that though. but would a tracksuit be appropriate even there?

But I am going to be 'consulting' for my countries tax authority soon. I wore a blazer to the take-in interview. I don't wear full suits myself as it is above my paygrade, but people expect to see at least business-casual in that kind of environment.

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#229
post #41

> Do Java programmers make more money than .NET programmers? Anyone describing themselves as either a Java programmer or .NET programmer has already lost, because a) they’re a programmer (you’re not, see above) and b) they’re making themselves non-hireable for most programming jobs. In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t be…

Stack is relevant though. If you need a front-end architect, and you hire someone with 10+ years Java experience, they aren't going to know the first thing about web accessibility, polyfills, bundlers, cross-browser support, etc. The domains of implementing microservices vs. writing front end code are fundamentally driven by very different problems. The stack an engineer has experience with can be one indicator of th…

> the first thing about web accessibility, polyfills, bundlers, cross-browser support, etc.

Almost all of these concepts could easily be learned in a few weeks by a talented engineer with strong fundamentals in software design and computer science.

Polyfills aren't exactly quantum mechanics. They're not some radically different mental paradigm that takes years to develop fluidity. If you already have a sound basis in the major software engineering concepts, learning polyfills is just a matter of reading the docs to learn the details.

Let's not forget that Jordan Walke was working on back-end infrastructure code just prior to inventing ReactJS. Miso Hevery was working on Java testing frameworks just before inventing AngularJS. So it's not like there's a history of front-end being such a unique problem domain, that it's impossible for outsiders to pick up.

The only major sub-domain of software that I think this may potentially be true of is embedded systems. And even then, that's a big maybe.

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#230

Earlier quoted context omitted.

Stack is relevant though. If you need a front-end architect, and you hire someone with 10+ years Java experience, they aren't going to know the first thing about web accessibility, polyfills, bundlers, cross-browser support, etc. The domains of implementing microservices vs. writing front end code are fundamentally driven by very different problems. The stack an engineer has experience with can be one indicator of th…

Is this the right way to hire? Not saying it’s wrong but I’ve taken a different approach which has generally worked out. Even if I was hiring for a specific role (front end), I care less about familiarity with specific bundlers or frameworks and something more like - “Can this person problem solve and deal with varying levels of ambiguity? Do they seem capable of figuring something out without a ton of direction?”

That is exactly the thing I select for. I recently had to hire 4 developers, and I was not all that interested in how many years of experience they had in javascript or typescript (our main language), and even less if you know Vue or Express (our stack). I mean, it's good to know javascript, and certainly ES6 or typescript, but I'm much more interested in: can I discuss stuff with you, do you have interesting opinions, can you make clear decisions in the face of unclear requirements, are you creative, and can you fix stuff and build features without anyone having to hold your hand? In case of doubt, knowledge of ES6 or Typescript or any relevant front-end framework (Vue, Angular or React) can make a lot of difference, but I'd rather hire someone who knows a dozen languages we don't use than someone who only knows exactly the one language we do use.
Post reply on HN