Live data from Hacker News

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

kalzumeus.com

231–240 of 316 posts

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

#231
post #73

There’s no shame in the word programmer and there was no need to culturally appropriate the word engineer from another profession. Bring back the word programmer.

More and more I think the word programmer has come to mean nothing and will continue to lose meaning. More and more people need to program for their work and would not call themselves “programmers” (Scientists, Marketers/DevRel, other Engineering fields, Support, Ops, etc). BTW, there are people who definitely “Engineer” software they are rare, but they exist, especially at the FAANGs. There are lots of people who ha…

"Engineers spend a lot less time programming than Developers do, because their primary occupation is solving tough problems with their colleagues through documentation, RFCs, etc."

Sorry but 100 times no. Engineering is about understanding and using the laws of nature in scientific terms (mathematics). Strength of materials, thermodynamics, hydraulics, that's the stuff engineers study and do.

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

#232

Earlier quoted context omitted.

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.

I don’t necessarily have anything against React as a technology, but as the old saying goes, a man with one ass can’t dance at two weddings. Almost everyone else at the company are better at the front end than I am but most haven’t taken the time to learn the backend. Why would I learn something, that I still wouldn’t be as good at in a year and couldn’t negotiate a higher pay based on bringing an above average amount of value to the company than other employees? I also wouldn’t be as competitive in the overall job market.

This isn’t directed toward you, just a general comment.

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

#233

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…

> 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…

As atomic points, I agree. Polyfills aren't rocket science. If the browser API is not defined, the use the polyfill function (at least, that's how most work, but then there's ponyfills, which don't pollute the global scope).

But front-end development of complex applications isn't done in a vacuum by one person. It's done by multiple teams, possibly distributed across different physical locations.

As an architect, what is your polyfill story? Does each team ship ES Modules that are later compiled by Webpack? Is each team responsible for loading their own? It's probably more efficient to handle it globally --knowing what all teams need at once as part of a build step-- to prevent duplicative loading of the same polyfill by 5 different teams.

It gets nuanced quick. Nobody can master all these concepts --and reasonable ways of managing them in distributed team environments-- in a few weeks.

And if you think JavaScript is "simple", I encourage reading "You Don't Know JS". What does "this" mean, in JavaScript? I could ask a handful of questions from the multitude of sections in this book, and people writing JavaScript for years wouldn't be able to answer all of them. React and Angular are such a thin slice of the overall problem. Even simple projects will require a dozen or so more NPM packages until you have something remotely useful.

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

#234

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?”

There is no "right way to hire". All "ways" are flawed and miss things. If hiring could've been solved by now, it would have already happened.

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

#235

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…

> 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…

>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.

Individually yes, but all of these things would take more than a few weeks - possibly months. With onboarding on an average software project also taking months, you could be looking at paying for a lot of unproductive time if you don't hire somebody with some prior knowledge.

The idea of language fungibility is a joke. Sure, it takes you a day to learn the basics of syntax in another language. Learning the whole ecosystem takes considerably longer.

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

#236
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…

> 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 been doing that one for your entire career. I think this is only true if what you're working on is simple, like crud apps. It takes longer to be intimately familiar with a language's concurrency model, pros and cons of major libraries and frameworks and the ability to make such decis…

In my experience folks can be reasonably productive essentially immediately in a language they've never touched if they're diving into an existing code base. Give them a machine that's already set up like the other developers, point them at a couple easy bugs or features, do some code reviews, and yes they'll be slightly slower through this process than someone that's already familiar with the stack, but not much.

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

#237
post #67

Earlier quoted context omitted.

Because ruby programmers are rare nowadays and your company still need people to build software. At least, that's my assumption.

They're not rare. I know a ton and many still write Ruby. Willingness to work on brownfield Ruby projects is rare; as with other similar systems like Django or roll-your-own Express stuff, such systems strongly tend towards chaos and a lack of maintainability after a certain point if they haven’t already had strong leadership end-to-end. In my neck of the woods, the folks who you want doing that work don't want to do…

> Willingness to work on brownfield Ruby projects is rare

After working in a dev agency that took on outside Rails projects several times while I was there, my conclusion is that Rails (not the only way to write even Web-focused Ruby, and not the only one I've used, but the only one that'll score you any points for hiring) is a pretty bad framework for any project that will have multiple teams on it over its lifetime, absent heroic technical direction & testing efforts that I've never actually seen in the wild—probably because young or outsourced teams picking Rails are doing it to move fast, over all other concerns.

You can take on or resurrect an average outside or old Rails projects. It's just slow and expensive.

Too much magic, too much room for doing things some way that the next person will never have seen before, too little grep-ability, too hard for your tools to help you.

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

#238

>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 been doing that one for your entire career. I've always been a bit baffled by notions like that. How in the world one becomes a professional in a foreign programming language tech in 6 months? It feels like every modern realworld battleworn programming stack (ecma, c++2x, .net, jvm w/…

I've more than once gone from knowing nothing about a language + ecosystem to releasing something comparable in quality to the norm for the platform, in three to six months.

It's mostly about knowing what you ought to be able to do. "Where's the hello world example? Let's get that deploying so we get in a good feedback loop. This is a GUI system that's not the Web, so probably there'll be event hooks or callbacks or something, I'll go look at how I respond to a click event and that should give me a good idea. And probably I'll draw with method calls of some kind and want to organize my code in such-and-such way as a result to keep the drawing code together, but maybe they have an XML design language or some other junk, I'll go check". Stuff like that.

Or "this is a web-focused backend framework so I need to figure out the idiomatic way to interact with storage systems like databases, how & where it's best to set headers, should see if it's got some standard way to manage migrations, et c."

You know what you need to do, the right way's a Google or glance at the docs away, and a lot of it's a once-per-project thing or something that can be quickly hidden behind a simple function call or just copy-pasted as necessary and appropriate. The rest is just refs/pointers, loops, objects, recursion. Normal shit everything has.

The hard part is usually the build & packaging system, in my experience, because those are usually terrible and are usually where the big hair-pulling multi-hour-losing unproductive speed-bumps show up. Big & popular doesn't make it any more likely to be much better or easier to figure out "best practices", as described in hip blog posts versus reality (see: Javascript).

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

#240
post #239

You shouldn't be able to call yourself an engineer unless you have a BEng, personally. Some places actually have laws against calling yourself an engineer without one.

I have a b.sc and a m.sc in mechanical engineering. Can I not call myself an engineer now anymore?
Post reply on HN