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…
Don't Call Yourself a Programmer, and Other Career Advice (2011)
221–230 of 316 posts
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#222Earlier 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.
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#223Earlier 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…
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)
#224Earlier 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!
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#225Earlier 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…
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#226> 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…
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> 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…
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#228This 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.
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> 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…
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)
#230Earlier 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?”