Don't Call Yourself a Programmer, and Other Career Advice (2011) • Hacker News Board

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

#281

Post by VonGallifrey » Mon, Oct 21, 2019, 1:18 AM UTC

hacknat wrote: post #73

Mistletoe wrote: post #65

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…

I am doing exactly what you describe as a "Software Engineer", but I would still call myself a Software Developer. Why? Because I don't think your definition is widely accepted like that. I especially think that because the law in my country disagrees.

For me to call myself an engineer legaly I have to have an Engineering degree. I don't have one, so I will not call myself that.

I am a Software Developer. I do the exact same things as the Software Engineer sitting in front of me. We work on the same type of problems in the same Avionic Project. The difference is that he has a PhD and I dont.

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

#282

Post by WrtCdEvrydy » Mon, Oct 21, 2019, 1:40 AM UTC

shantly wrote: post #237

eropple wrote: post #125

Earlier quoted context omitted.

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…

Honestly, I find Rails projects to unupgradeable.

We found it to be easier to just rewrite the project when moving between major versions (Rails 4 to Rails 5 for example). Shoehorning old functionality into a newer Rails just made this inconsistent.

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

#283

Post by marcosdumay » Mon, Oct 21, 2019, 1:46 AM UTC

pytester wrote: post #277

dcolkitt wrote: post #259

Earlier quoted context omitted.

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

> There's definitely a sweet spot in terms of stack specificity.

The GP's calculation had a very important weakness that it does not take retention under account.

The sweet spot will be mostly determined by retention. And the very bad places that have impossibly (sometimes literally) specific requirements are probably correct on requiring a narrow set of competences. But of course, they would gain more by improving themselves so the developers don't quit as often.

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

#284

Post by scarface74 » Mon, Oct 21, 2019, 2:04 AM UTC

jghn wrote: post #273

scarface74 wrote: post #248

Earlier quoted context omitted.

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.

Why else would most companies have open reqs if they don’t see a need for man power soon unless you are one of the four or five big tech companies that are trying to accumulate smart people (tm)?

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

#285

Post by confidantlake » Mon, Oct 21, 2019, 2:05 AM UTC

dcolkitt wrote: post #229

JMTQp8lwXL wrote: post #167

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…

Jordan Walke and Miso Hevery are outliers working at companies that pay a lot. An average company is not going to be attracting talented engineers with strong fundamentals. They are going to be attracting engineers with average aptitude and average fundamentals.

An average company, paying average wages, solving average problems is better off getting an average developer specialized in the area they need.

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

#286

Post by bhldev » Mon, Oct 21, 2019, 2:33 AM UTC

scarface74 wrote: post #170

bhldev wrote: post #161

Earlier quoted context omitted.

It's not an easy problem. It's a database concurrency issue and well beyond the skillset of most mobile devs. Database isn't even a required course for a compsci degree it's usually an elective. My point is the problem you think you solved, you didn't and it will break under dozens of scenarios. Maybe the clients are happy and they think it works but you just haven't encountered the case where data goes missing or ov…

So you’re saying “it’s not a good idea” to have software that actually fulfills the need? The mobile app that doesn’t work in the majority of use cases to solve the problem that it was meant to solve is useless. And yes “the problem” we solved, a mobile app that could route field technicians dynamically at a level of quality we needed we did solve. The word "enterprise" is an euphemism for low cost and potentially lo…

I value experience a lot, over almost anything.

What you mention is very dangerous to the data. Take the medical app example. Suppose there's an app to update a chart that doctors carry around. Suppose there's five doctors and/or nurses working on the patient. Whose prescription or orders do you take? On top of that it gets worse -- there might be dependencies between the orders, orders might be to countermand other orders or in response to others which may or may not exist. It is not a problem that any algorithm or programming can solve, because the whole point is to take the experience and skill of the doctors which is being blindly ignored for some process that the doctors may or may not be aware of who submit the information. Similar problems could appear for any of the examples you mentioned if you dug hard enough.

As for the submission you can simply ban submission unless you have an active Internet connection. 737 Max is also "real world experience" Boeing panicked at Airbus and instead of going through a 10 year design and 10 billion dollar process for a plane they surrendered to market realities at the cost of lives. The fact that "enterprise" has onerous business requirements or even legal requirements demanding technical sacrifice doesn't make it any less technically wrong. If asked to make a sync on the client side I would make it as simple and straightforward as possible and assume nothing.

I suppose so long as it doesn't cost lives or ruins people I don't particularly care if you value handling data on the client in this way as a qualification for "enterprise" mobile developer. As long as it's "good enough" to meet the requirement, great. But it doesn't mean I like it, and it doesn't mean one should ignore technical flaws. Unless it's ACID you don't guarantee anything it's just a feel good (and possibly done in a much simpler way). For all the scenarios you mentioned I can mention another half dozen scenarios or even a very simple one, one person with same seniority making exactly the same change to the same record. Then your system tosses one or the other or even merges them -- in other words you dive into expert systems, NOT anything to do with "syncing".

Experience is important but there's a theoretical foundation to everything and it's wrong to expect an offline node in a distributed network to act as a source of truth for any period of time. Sorry.

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

#287

Post by shantly » Mon, Oct 21, 2019, 2:50 AM UTC

WrtCdEvrydy wrote: post #282

shantly wrote: post #237

Earlier quoted context omitted.

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

Honestly, I find Rails projects to unupgradeable. We found it to be easier to just rewrite the project when moving between major versions (Rails 4 to Rails 5 for example). Shoehorning old functionality into a newer Rails just made this inconsistent.

Good call, coming on to a Rails project that's been upgraded—or worse upgraded twice—is... usually very unpleasant.

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

#288

Post by bdowling » Mon, Oct 21, 2019, 3:13 AM UTC

cool-RR wrote: post #58

bdowling wrote: post #37

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…

The billing department is a profit center because it converts accounts receivable into cash and there are metrics like days sales outstanding that can be used to directly measure their impact on the bottom line.

Cost centers on the other hand are indispensable, but evaluating their impact on the bottom line is hard to quantify and therefore subjective.

Again, it’s not fair to the invaluable work done by the cost centers, but that’s what it is.

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

#289

Post by sanderjd » Mon, Oct 21, 2019, 4:12 AM UTC

pytester wrote: post #277

dcolkitt wrote: post #259

Earlier quoted context omitted.

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

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

You think? I went the other direction and I don't think it was so hard. The language was the easy part of onboarding, the hard part was all the company specific stuff.

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

#290

Post by wwweston » Mon, Oct 21, 2019, 4:46 AM UTC

dcolkitt wrote: post #229

JMTQp8lwXL wrote: post #167

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.

The most important 67-80% of front-end work can probably be learned in a few weeks by an experienced engineer who already has a high level understanding of the web. The last 20-33% hides some things that are trickier to wrap your head around, along with more than a few WTFs, and a never-ending stream of subtle cross-browser differences.

It may still be plausible that a talented engineer with strong fundamentals in software design and cs could cover the ground quickly. But the message of the "don't call yourself a programmer" piece might be understood as being as much about how you're going to spend your time as it is how you're classified professionally (though those are certainly related): are you a stack-whisperer, or are you a badass problem solver with expertise in translating a problem domain into a formal-ish system which enables expands the capabilities of the human system (and networks of machines) it's embedded in?

My bet as someone who did years of front-end focus is that for all but the truest 10xers, if you focus on front-end and try to be thorough, your risk of being a stack-whisperer jumps dramatically because of how much of your time corner-case ephemeral arcana will chew up. Front-end is certainly not the only place in the industry where we've let that hazard run away with the lives and time of too many talented people, but it's a popular one.