Rules of thumb for a 1x developer • Hacker News Board

Re: Rules of thumb for a 1x developer

#221

Post by scarface74 » Thu, Apr 30, 2020, 3:10 PM UTC

TheOtherHobbes wrote: post #141

LandR wrote: post #75

Earlier quoted context omitted.

I keep hearing that it's like this in the US. In the UK I don't know anyone in their 40s struggling to find software developer jobs in the UK! I'm almost 40 and are constantly getting harassed by recruiters. My mate in his 60s not long ago got hired for a software developer role, and easily at that. Two interviews and he got an offer. Another mate near 40 stepped back from manager type role into a developer role, and…

"Cultural fit" SV start-ups need bright shiny twenty-somethings for their "About us" pages and their IG lifestyle feed, with a few wise old thirty-somethings to ride herd on them. It leaves room for the forty-something and fifty-something VCs to do what they enjoy, which is pretending to be the team coach. Put in some wrinkly old guys - or worse, some old women - and there goes your brand identity.

Luckily there is an entire country outside of SV....

Re: Rules of thumb for a 1x developer

#222

Post by ausjke » Thu, Apr 30, 2020, 3:10 PM UTC

noad wrote: post #21

I used to get called a 10x developer, I was also called a rockstar and a ninja and a 100x dev and every other compliment that was hip. Then I hit 30. That type of talk stopped. Then I hit 40. Now I will not be considered for any entry level, mid level, or senior level software dev job anywhere in the United States, despite being very desperate and willing to relocate for anything. Doesn't matter. Too old. I'm suppose…

I started my career at Motorola, I saw so many senior(read: old) engineers working efficiently and staying updated. They're eager to teach newcomers. It gradually stopped when the outsource era came.

I notice over the years a few star players in their 50s and even 60s are either unmarried, or married without kids.

I have kids and I'm in my 40s, I plan to work until 65 for coding. If nobody hires me, I will try to get something done(SaaS?) or consultation from home. I probably don't need that income to survive(by then the kids will be out so the finance burden will be more tolerable). Working is the meaning of life for me, it has nothing to do with my age or if anyone hires me. I will keep studying and working no matter what.

Re: Rules of thumb for a 1x developer

#223

Post by scarface74 » Thu, Apr 30, 2020, 3:11 PM UTC

throwphoton wrote: post #218

scarface74 wrote: post #158

Earlier quoted context omitted.

I’m 45, and was last in the job market in 2018 and before that in 2016. I’m in Atlanta. The last two times I looked for your standard senior/lead enterprise dev roles it took less than two weeks to get an offer just by using local recruiters. Edit: There is a huge difference between random spam from recruiters who throw a big net and working with local boutique recruiters who have relationships with local firms. I ig…

I'm in my 40s in the SF Bay Area and recently landed a new software development job. The process took several months. My initial interviews were disastrous; it had been many years since my last job search and I didn't know I wasn't prepared for the "leetcode era". Drilling on "leetcode medium" problems with a time limit got me to the point where I was at least in the game that's being played nowadays. It wasn't prett…

Pro tip: get out of SV....

Re: Rules of thumb for a 1x developer

#224

Post by romanows » Thu, Apr 30, 2020, 3:13 PM UTC

jordanpg wrote: post #138

engrsrce wrote: post #122

Earlier quoted context omitted.

Well that's pretty naive. I've worked with some pretty good teams that wouldn't work any other way. I suspect you've only worked at places that abused agile as described here... https://ronjeffries.com/articles/language-of-hatred/

No, I've worked in places where it works just fine. The point is that, at the end of the day, it boils down elaborate processes to break things up into two-week chunks of work. That's it. That's the bit I thought was a concise, excellent summary. Sometimes, for certain flavors of apps and tech and teams, that model works splendidly. Sometimes, it is silly administrative window dressing that is completely disconnected…

Agile is the opposite of "closely scripted, narrowly defined workflow is a one-sized-fits-all solution to optimizing teams under all circumstances and contexts." You're thinking more of Scrum?

Re: Rules of thumb for a 1x developer

#225

Post by elwes3 » Thu, Apr 30, 2020, 3:15 PM UTC

lotash wrote: post #203

noad wrote: post #21

I used to get called a 10x developer, I was also called a rockstar and a ninja and a 100x dev and every other compliment that was hip. Then I hit 30. That type of talk stopped. Then I hit 40. Now I will not be considered for any entry level, mid level, or senior level software dev job anywhere in the United States, despite being very desperate and willing to relocate for anything. Doesn't matter. Too old. I'm suppose…

I'm a SWE hiring manager. I love to hire older, experienced devs. I want somebody who can be self-directed and can effectively talk to stakeholders to come up with a good solution. My experience has been that (some!) older developers are more able to do this. That said, if you're an older dev that hasn't kept up with the times, I'm prob not going to hire you. I even work in SV :)

Uh then there is 0 difference between an older dev and younger dev (by your own definition other than age). An older dev that 'knows all the new tech' may not have the concentration you need. You can not tell me as a hiring manager if you see someone changing jobs every other year you think it odd? I know I do when I see resumes like that. If they have the right skills I ask them to explain it.

You are just justifying being ageist. You mental gymnastics to do so are in your second to last line.

Exp in older stacks, that are 'obsolete' in your eyes, has helped me so many times with newer stacks. They usually make the same mistakes/patterns and have the same bits connecting it together at the OS level. A more experienced dev from another stack may say 'hey if this stack had XYZ from this other stack this would be so much easier' They then will get that thing done.

If you are skipping people because they do not know your particular stack you are missing out on a lot of people. The fresh young grad is not going to know any stack and will have no exp to draw upon when it goes sideways. That is why you pair them with someone who does have that exp to draw upon. Sometimes you want that crusty old ways too. Linux is a hodge podge of tech smashed together drawing from well over 40 years of tech stacks. Each with its own quirks.

Re: Rules of thumb for a 1x developer

#226

Post by timerol » Thu, Apr 30, 2020, 3:15 PM UTC

theli0nheart wrote: post #152

WJW wrote: post #98

Earlier quoted context omitted.

Of course there is, but that's not the point. Every large organisation has organisational issues and nobody in the history of humanity has found a way of preventing them yet. The only thing you can do when the group sizes get large is to try and keep the problem under control relative to how bad it is at other large companies.

I'm lost; what specifically is not the point? As far as I could tell, the "reason" given by the OP for this waste was attributed to Amazon's scale. Could you explain how company size and broken corporate structure are correlated? Or explain why 20+ person-years of engineering time wasted isn't a symptom of broken corporate structure?

> I'm lost; what specifically is not the point?

That there is an organizational issue. Of course there is an organizational issue. There will always be organizational issues.

> Or explain why 20+ person-years of engineering time wasted isn't a symptom of broken corporate structure?

Oh, it's definitely an organizational issue here, that's just not the main point. If you're willing to call this a "broken corporate structure," then you should revise your opinion of every company with more than 50 employees downward sharply. This is a normal corporate structure, not a broken one.

> Could you explain how company size and broken corporate structure are correlated?

When there are enough people, you will always end up with conflicting incentives somewhere. A larger organization will have more of these. In this case, it seems to be a clear case of competing priorities: IT wants to secure systems, and developers want to be maximally productive. I'm sure some folks in IT view Amazon paying ~$7M as a fair cost to remove known vulnerable tools from their infrastructure.

Re: Rules of thumb for a 1x developer

#227

Post by Raphael_Amiard » Thu, Apr 30, 2020, 3:15 PM UTC

cloverich wrote: post #209

Kudos for the open and honest assessment, I enjoyed reading it. Some feedback for your journey: Drop the focus on languages. Choose one (popular) language and focus on understanding it well. The best thing you can do, is find some open source project with high quality code in that language, and study it. Slowly, how long it takes does not matter. The end result is you will pick up best practices and styles you did no…

> Drop the focus on languages. Choose one (popular) language and focus on understanding it well

While I understand this advice, your mileage might vary. I had the exactly opposite approach and did learn a ton of different languages, on the end making it my area of expertise as a compiler developer and language designer. Of course that's niche, but knowing only one language will eventually become a blocking point for every developer, especially in the modern world.

Re: Rules of thumb for a 1x developer

#228

Post by dkryptr » Thu, Apr 30, 2020, 3:18 PM UTC

noad wrote: post #21

I used to get called a 10x developer, I was also called a rockstar and a ninja and a 100x dev and every other compliment that was hip. Then I hit 30. That type of talk stopped. Then I hit 40. Now I will not be considered for any entry level, mid level, or senior level software dev job anywhere in the United States, despite being very desperate and willing to relocate for anything. Doesn't matter. Too old. I'm suppose…

I'm not sure if you're looking at large organizations or what, but where I've worked in the midwest (one company with less than 100 employees and a startup with 5), both have had software engineers/developers older than 40. In fact, we sometimes hired people that were specifically older with more experience at the company with less than 100 employees.

Maybe you just need to tune which companies you look at and/or lower you salary expectations. I'm not sure honestly. Just thought I'd try and give you my experience.

Re: Rules of thumb for a 1x developer

#229

Post by sbarre » Thu, Apr 30, 2020, 3:18 PM UTC

theli0nheart wrote: post #152

WJW wrote: post #98

Earlier quoted context omitted.

Of course there is, but that's not the point. Every large organisation has organisational issues and nobody in the history of humanity has found a way of preventing them yet. The only thing you can do when the group sizes get large is to try and keep the problem under control relative to how bad it is at other large companies.

I'm lost; what specifically is not the point? As far as I could tell, the "reason" given by the OP for this waste was attributed to Amazon's scale. Could you explain how company size and broken corporate structure are correlated? Or explain why 20+ person-years of engineering time wasted isn't a symptom of broken corporate structure?

It's unlikely that this went entirely unnoticed for 4 years, and I would guess that when the problem was understood, someone did the math on staying the course, versus starting over or reversing course.

And after all the internal calculations were complete (which factor in way more than technical effort by a small dev team), they intentionally stayed the course.

This is probably an extreme example because an internal wiki that is used company-wide will have an incredibly complex and hairy stakeholder matrix (both business and technical), which means consensus is very challenging.

At some point the cost of the meetings required to work out a solution (both in time spent, and in time not spent on core work by the stakeholders) probably exceeds the cost of just letting a small team brute-force their way through a bad solution.

Cost here isn't just money, it's focus, morale, disruption, conflict, risk, etc..

Keep in mind that you have the benefit of hindsight, and the comfort of looking at it from the outside, with a very incomplete picture of all the constraints and pressures at play.

Re: Rules of thumb for a 1x developer

#230

Post by kakwa_ » Thu, Apr 30, 2020, 3:19 PM UTC

skywhopper wrote: post #116

I'm somewhat perturbed that the entirety of the "DevOps" section is advice to get an SRE on your team because an SRE's job is to "be online after hours". That's an incredibly dismissive and reductive perspective on the expertise and insight that an SRE (or any ops staff) could bring to a project, and it sounds like this person--or maybe their entire team--is doing a really bad job of owning their own junk. I'll make…

This is indeed an incredibly dismissive view, only seeing the SRE as the poor soul you offload responsibility of things running well in production, despite the fact he is likely to have far less insight on what might go wrong and means to fix things.

Being basically in this position (but in a large follow-the-sun team, so I'm fortunate enough to not be paged at night), I can only underline the deep frustration such views can generate. Being paged every 10 minutes, being asked to fix things you have no control over, getting answers like "what? the server is overloaded? it's an infrastructure issue, not a bug in our code" and seeing developers cry when they get a ticket a day, when at the same time each SREs in the team is receiving a dozen, it can lead to some resentment.

A saner approach is to have the SRE as the first line to filter bugs/alerts/tickets out, but being able to call a developer if required. The SRE can also be an active team member with more insight on production constrains and pain points and maybe system architecture recommendations for the whole team. Also, in my opinion, developers should be an active part of running things in production, otherwise the whole dev team can lose touch with reality and lose sight on how well or not things are actually running.