I see people saying it takes a few weeks to pick up a language, those people are programmers and not software engineers.
Also, this career advice shouldn't be considered advice, it's simply opinion.
Don't Call Yourself a Programmer, and Other Career Advice (2011)
271–280 of 316 posts
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#272Earlier quoted context omitted.
Part of the point of the author is that if you're talking to the low-level HR people, you're not talking to the right people. That's not how interesting people and interesting jobs find each other.
Not everyone can be as famous as Patrick. That's not how celebrity works. Tens of thousands of people get great jobs the normal way by joining a company as rank and file and working their way up, and then getting invited to join their former co-workers' new companies later.
Patrick wasn't that famous when he wrote this.
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#273Earlier quoted context omitted.
It's the first thing some hiring managers look at. Speaking for myself as a hiring manager I'm not looking for specific tech stacks. I'm looking for general patterns. Someone who has spent their entire career doing front end work is unlikely to be a great fit for embedded development and vice versa, but I don't care so much about the specific technologies they used in the process. My experience has been that concepts…
Until your customer needs a feature a month from now and not a year from now or you only have a six month runway....
The percentage of hires for companies in that situation is going to be extremely small, yet the "hire for tech stack" motif is cargo culted throughout the industry.
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#274There’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…
>An engineer is dealing with a significantly unique problem space that has only been addressed by theory, if that.
This is a very high standard for defining engineer and I'd guess most practicing engineers don't meet it. Sure, there's people bridging the gap between theory and practice, but most engineering effort goes into applying the same well-understood theory and practice to slightly different situations. I'd posit that your definition of software engineer is closer to what most people would call a research scientist.
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#275Earlier quoted context omitted.
This shouldn’t be a problem in a business with well defined roles. Boss/manager says customer wants x. I don’t care why they want that, and I may even think it’s dumb, but I can make it happen. After all, I get paid to solve problems with code, not interpret customer requests.
I was once interviewing for a job as a senior engineer/lead role. The CTO - my eventual manager - was asking me a lot of high level technical questions even though he was a very competent developer. Then, another developer who had been there for a decade asked me how I would go about writing “address validation routines” - It was a real world problem he was facing. I told him that I wouldn’t. That’s not the vertical…
> I’ve spent my entire career asking questions and making sure we were building the right things.
But this gets back to what OP was saying. Spending time asking questions == spending time in meetings. Not writing code.
I’m not advocating for never asking questions or suggesting better ways, just saying that I prefer to work where someone else handles the bulk of that so I can focus on what I specialize in.
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#276Earlier quoted context omitted.
> 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. How about average engineers with average fundamentals? The kind most people will on average be hiring and working with.
Another career advice: Try to not join a company which mostly hires average engineers with average fundamentals.
Most engineers are average. If you are above average you are likely working at a company that pays above average.
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#277Earlier quoted context omitted.
>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 pr…
> 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, So, let's say that is the case. The lesson is that hiring is expensive and risky, even if you find a candidate whose experience exactly matches your stack. Like you mention, just onboarding for the internal technology and project itself takes months. You're…
>And the reality is that dropping stack requirements drastically improves the candidate pool. For one you have way way more candidates to select from.
There's definitely a sweet spot in terms of stack specificity. There's very little issue hiring a flask developer if you need somebody to work on django. However, if you're a ruby shop and you hire a java developer - even if they are great - you've potentially doubled or tripled your onboarding time.
>All of which means that if you insist on [X] experience, most of the time you're scraping the bottom of the labor market barrel and getting mediocre engineers.
I don't think that's necessarily true. Nonetheless, this could be market specific. I can imagine that hiring a developer in, say, Ohio might make your approach more worthwhile compared to hiring in SF, where the talent pool is deeper.
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#278Earlier 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…
> 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.
The big problem with embedded is that when things go wrong, it has a cross cut with electrical engineering--you have to understand datasheets, read a scope, and understand that digital signals sometimes aren't.
I have never known a good embedded software person who is software-only. Even DSP-types with EE degrees don't often operate on hardware very well.
Generally, the best embedded software types are good hardware EE's and passable software people.
I consider myself a very good embedded engineer, but my software is merely "straightforward". Of course, the best software people I know claim I should take that as a compliment, and they are all happy to work with my code.
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#279Earlier quoted context omitted.
Learning rate doesnt really matter anymore. If you want to do really well you basically have to work for FAANG, who will basically only vet you on your algorithms skills. They completely negate everything else. So none of it matters, all that matters is if at interview time you can find the most optimal solution. If you want to work for companies paying less money, then sure, experience counts.
There are lots of opportunities to make that same type of comp at non FAANG companies. They're just not so clumped together, and don't have a cult-like following pumping them up in every thread.
Much harder to make 300k+ at a non faang/unicorn corporation
Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)
#280> There’s nothing wrong with this, by the way. You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter. Andrew Yang brought this up in his interview with Joe Rogan a few months back; how people in The Bay will basically say, "Yes, we're trying to automate away these jobs." And to some extent, we're trying to automate away jobs in the tech in…
His assertion is wrong, by the way, only some programmers are contributing to job losses in other domains. I expect that many of us are just building products. Perhaps that's their way of making themselves feel better, when they say that everyone 's doing it.
Some programmers create jobs too. App stores for iOS and Android created an entire mobile app industry, as one example.