Hacker News Reader

Comment by erikpukinskis | Hacker News Reader

I've been doing some job interviewing lately, at 37.

I do find that companies seem to know how to evaluate young programmers: just test them on their knowledge of your tech stack. Any young coder who is good and is working in that stack will know the basics. The bad ones won't.

For older coders, I'm not sure that same signal works. I've forgotten more frameworks than most coders will ever learn. I mostly don't care about programming languages, they're roughly the same and I can learn a new one in a couple weeks.

I know technologies like Rails and SQL, but I don't play with the new toys as much as I used to, becuase lately I would rather solve a new problem or build a new tool than learn a new tool.

But how do you evaluate a coder on their ability to solve problems? Much harder.

Even more difficult, how do you get a 24 year old coder who only knows react and FireBase to evaluate a 37 year old coder who has built web frameworks from scratch?

It's another world, and a lot of companies just don't bother.

Thankfully I have no desire to work at any of those companies. I solve problems. If a company can't hire for that I don't belong there. There are plenty of companies trying to hire people to solve actual problems, not just put coder butts in seats.

View on HN

This whole "learn a new one in a couple weeks" mindset is toxic and needs to die.

Yes, you can learn anything at a superficial level in a couple weeks. If you've spent the last ten years maintaining an ASP.NET WebForms app running on IIS, then within a couple of weeks, you can contribute code to a Go microservice running in Kubernetes and using Kafka.

And that kind of "basic competence, with the ability to learn more" is what hiring managers want out of a junior dev, so if you don't keep your skills up, well, great, you're as useful as a junior dev.

But what they want out of senior devs is people who know the ins and outs, who understand what to do and why to do it and can explain that to others, who can avoid the pitfalls of bad tech choices and misguided implementation patterns.

If you've got decades of experience on your resume, my guess is that you want to be evaluated as a senior dev. And if you're a senior dev who doesn't know modern tech, then... you're not that useful. Your encyclopedic knowledge of the WebForms event lifecycle doesn't give you any particular insights into the design challenges of a microservice ecosystem; your ability to tweak IIS for maximum performance won't help you write a Helm chart.

If you want to be hired as a senior dev, you need to understand how the modern world works, and all the posturing around "I could learn it in a week" or "I prefer to focus on problems" doesn't impress anyone.

It's not toxic, it's dumb.

I get where you're coming from, but I didn't get the impression that GP was ignorant to new developments. In my experience the most important thing is really wrapping your head around a domain to be able to solve concrete problems in it. Whatever framework or programming language you choose to solve those problems with is peripheral, really.

Also, most coding is maintenance. So yes, an experienced developer in some language is really worth a lot when you initially start out designing your system. But most of the work spent on that system will be maintaining and extending it and to be able to proficiently do that you need to:

1. Grok the problem domain, so you can connect the real-world / problem you're trying to solve with the code in front of you

2. Have a grasp on the limitations of your own system, which will come with experience as you work longer on it

If you really are a senior technical person, you have many valuable skills that are not tied to a tech stack. Otherwise you may have a related title but you are really just a technology domain expert - which is sometimes very useful and valuable, but it's not the same the same thing at all.

So yes, it's helpful that people keep current, and obviously waiting for a new developer to get up to speed on the particular stack is always a cost (and it isn't a couple of weeks, for anyone). However, if what you really need is a senior person, it may well be worth that time.

Seeing this assumes the hiring manager understands how software is actually produced and maintained, not just what their current tech stack needs. It's surprising how often this isn't true, but a contributing factor is how mid level mangers are made - which is related to this discussion I think.

What I'd say to that is, yeah, it's true that a senior dev will have skills that go beyond a particular tech stack -- but if you're working as a dev, then those skills are still tied to your technical knowledge.

You might be great at mentoring... but you have to know the stuff to mentor people in it. You might be great at communicating with stakeholders... but you have to understand the technical constraints of your system in detail to have that communication. You might understand principles of software design and debugging... but you still need to understand the particulars of these technologies to make your design or to focus your debugging.

And yeah, you can learn the tech stack, and a company that really needs a senior dev eventually could do okay to hire a senior dev with out of date skills, and wait for them to get trained up. But don't plan on it taking three weeks, is all I'm saying. To really get to that point of fluency and domain expertise takes longer.

(And also, one of the things that senior devs are supposed to do is evaluate new technologies and figure out when and where adopting them can make sense. If you've fallen so far behind on learning new tech, then it's not clear if this is something you're able to do -- maybe it is, and you just worked for a workplace that stifled adoption of new tech, or maybe you're someone who'll just learn what you need and then stop paying attention.)

While I see what your saying, a lot of your language seems to come from the idea that tech is a progression, that we are moving "ahead" always, and that people get "left behind".

That's mostly not true. While there definitely have been advances, tech is also very faddy and repeats itself. Trends are often reactive, techniques repetitive. Someone who has been around for long enough to see some of these waves resolve themselves is in a much better position to evaluate current and upcoming approaches. Technologists also tend to be myopic, and view the things happening in their own tiny slice of the industry as "what's happening". There is a whole universe of interesting stuff on the go that you are at best barely aware of.

Personally, if I'm hiring senior technical people I'm much more interested in their continuing level of curiosity and engagement with something, rather than particular stacks.

So maybe you are worried that your candidate who has been doing ASP.NET WebForms for the last decade on IIS will have a hard time getting up to speed on your use of TypeScript and React ... but if I find out that she's also being building raspberry PI infrastructure for fun and messing around with the Julia language to implement a cellular automata project I'm not all that worried about their ability to get up to speed, even though none of that stuff will get used by the team.

But yeah, it doesn't take 3 weeks. It doesn't actually take 3 weeks for a new dev already well versed in your technologies, with rare exceptions. At least not to be firing on all cylinders.

The thing is, a huge number of teams really, really need a good senior dev. They often don't think so, and often erroneously think they already have some... but they don't. Instead they have people who had "Senior" (or "Staff" or whatever) added to their title because they'd been there for a little while. And every piece of work the team produces suffers for it. So yeah, it's typically worth the investment.

Now granted, that assumes you are good at identifying talented people. This is actually a big ask - and one of the issues surrounding the OP's questions really comes back to that. I think that a lot of software and technology development suffers fairly systematically from poor quality middle management. One of the symptoms of this is the "ageism" discussed here, but it's only one of many....

Yes. These days gRPC is a new technology. And yet RPC has been around in one form or another since the 1960s.

   then those skills are still tied to your technical knowledge.

I think this is a problematic way of looking at it. Thing about it this way: If you are hiring a fairly general developer or engineer, their overall impact is going to be determined by something like 30% technical/ 30% problem solving and communication / 30% teamwork & fit, leaves you 10% to move around in those categories. In the much rarer case you are hiring a domain specialist, it is something like 60-70% technical. But you probably aren't hiring someone like that, or shouldn't be very often.

Focusing the hiring too much on that first 30% impact gets you in trouble.

If you’re competing as a “general developer” with ten years of experience, you’re a commodity that is competing with everyone else and if you aren’t knowledgeable about the tech stack we are using, you’re at a disadvantage. The last thing I want is to hire someone who has been doing Webforms for 15 years when I can find someone that has been keeping up. Why should I have sympathy for someone my age who didn’t have the wherewithal to keep up when I can be aggressive about it?

I know developers in thier 30s/40s/50s who are both great developers/architects and have current skills. Why would I settle?

I think you missed the point I was trying to make, I’ll try and summarize. There are two parts. If I’m hiring you as a 10 year veteran “general programmer”, I’m going to be very interested in the non-tech-stack skills you have developed (i.e. the other 60-plus percent of your impact). And let’s be honest, the vast majority of the 3 year experience “general developers” are weak there. The other point is that technology isn’t a straight forward progression, so while it isn’t great if you have been “stuck” in a tech stack you consider obsolete, by itself that shouldn’t be enough to reject you.

Two other points: First, of course when hiring you want to find the “perfect fit”, but you almost never do, so you have to make tradeoffs. Hiring an inexperienced person with the “right” tech stack when you really need to bring experience into your team is a common anti-pattern. Secondly, as a hiring manager you need to properly understand the difference between “10 years experience” and “one year of experience, related ten times”

Agree with all this, but I'll also say that if you're an experienced developer who hasn't kept up with the times, that's not just a fact in itself, it's also a signal about what kind of developer you are. Most of the best developers are active learners who are always trying new things just as a matter of course.

So if you only know old tech, I'm a lot quicker to believe that you're a "repeated ten times" person.

>If you've got decades of experience on your resume, my guess is that you want to be evaluated as a senior dev.

And this is where ageism rears its head.

If two people apply for the same position, and you're OK hiring someone who has only 2 years of experience for the position, don't ask for more from someone who's been working for 20 years.

They get paid very differently, is the thing.

Why do they? The older candidate may have a higher expectation, but as an employer, the compensation for a particular position should be somewhat fixed. If the older candidate doesn't offer anything more than the "inexperienced" one, offer the same salary you would the inexperienced person. They can always say "No".

Trust me: There are plenty of older programmers who do not expect a higher pay because of their age. In my career, whenever I hear "older people expect a higher salary", it has almost always been by employers/managers, not by actual older professionals. On the other hand, I've met quite a few programmers who complained they didn't get an offer or were told they were ruled out because they were "too senior", and the complaint almost always was along the lines of "I was not asked salary expectations".

I have a former manager who is in his 50s. As soon as his kids graduated he self demoted to a full stack developer working with React/C# and Azure.

I have another friend in his 40s who took a job that let him work from home who is in his 40s and it pays less than he was making when we were working together.

Not as differently as you might think. When I was more junior, I assumed the wage increases would continue as they had been. But they flatten out after 10-15 years of experience, to the point that the salary of someone with 15 years of experience is probably the same as someone with 30 years of experience.

It’s not really gloating; I’m in the same situation as GP - I’ve worked enough with languages and their ecosystem to apply those skills to new languages and ecosystems. It takes me around 5-7 days to grok a new language and how to be pretty good at it with its tools/frameworks/idioms. Having experience where understanding basic fundamentals make it easier to extend to a different implementations.

The language + tools aren’t barriers anymore, the interesting part of solving business problems and how to apply the tools become the fun ones.

Yeah, this is how I see it, too. Their example kind of gives away that they didn't understand.

Once you've learned and used a half-dozen imperative languages day-to-day, there's very little new when picking up another imperative language. It's mostly mapping common concepts onto new syntax, plus some new features and maybe quirks/gotchas.

Silly little example: After an hour of reading a Go tutorial, and having never looked at the language before, I was able to diagnose a bug a co-worker had been struggling with for two hours, because I recognized the pattern from something similar in Django (a python framework). Now knowing what to look for, a quick Google search had the exact answer to the problem right in the first result.

So do you think you could pick up and become a useful iOS Dev in two weeks?

Depends on the context. As part of a team (code already exists that I can reference), and simply "useful"? Less than that, probably about one week at most.

I wouldn't be doing anything large or complex in that short a period, but absolutely can become useful with smaller stuff in that period.

And I say this with experience, thought in a different context: Years ago my manager introduced me to a new codebase by giving me a bug to fix. It was in a Django site, and I'd never done any python before. Took about half a day to figure out what was going on (for comparison, nowadays it would maybe have been 20-30 minutes), and a bit more to fix.

But I did figure it out on my own, taking some work off of another developer who was focusing on more complex work. I would call that "useful".

That’s just the point, as a “senior developer”, I’m looking for someone who can select “New Solution” and start a project from scratch or at least start a new major feature. Anyone can pull up an IDE in almost any language, step through existing code, pull up a watch window and fix a bug. That’s something developers can do with three years of experience. Bug fixing is something you put your more junior developers on.

I have no idea why all of the old folks (again I am in my mid 40s) consider it some great skill that excuses them from actually keeping up with what’s going on in the industry.

Several things on that tangent:

* My bugfixing example was indeed trivial, just the first thing to pop into my mind. It was mainly aimed at the use of the word "useful", which is woefully ambiguous.

* Sounds like we agree when talking about someone who already knows the technology stack.

* No matter how skilled the developer, there will be ramp-up time when they not only don't know the framework, but also don't even know the language.

* That ramp-up time being significantly shorter for a senior dev is what we're talking about, and how selecting for the specific stack like you're describing isn't necessarily going to be worthwhile - learning the domain is likely to take longer than learning the technology.

Oh, and:

> Anyone can pull up an IDE in almost any language, step through existing code, pull up a watch window and fix a bug. That’s something developers can do with three years of experience.

Thanks for the compliment I guess; I was describing something from around 3-4 months into my first job.

No matter how skilled the developer, there will be ramp-up time when they not only don't know the framework, but also don't even know the language.

And if a company is using a popular language/framework they can find senior developers who know the language and the stack. Why should they hire someone who hasn’t taken the time to learn both?

That ramp-up time being significantly shorter for a senior dev is what we're talking about, and how selecting for the specific stack like you're describing isn't necessarily going to be worthwhile - learning the domain is likely to take longer than learning the technology.

Not really. If someone has ever been exposed to a similar framework - take your typical MV* framework for example - even a developer whose only been active for three years can easily transition.

I have no idea why old folks (putting myself in that category) think they can get by without keeping up. Do you really think that someone who has 15 years of experience but haven’t kept up with the industry won’t be at a disadvantage over someone with 5 that has? On the other end, you have people like me that knows what it’s like being behind the curve and vowed never to put myself in that situation again.

You can’t imagine how long it took me to unteach a 50 year old who had been doing ASP.Net web forms for years how to even develop in ASP.Net MVC using server side rendering let alone client side frameworks.

He was only eighg years older than I was but didn’t keep current

the advantage of older developers is that they have seen the same patterns before. For instance, younger devs might think microservices is the hot thing while an older dev is thinking that it just looks like a poor man's erlang from the 1970s and knows to wait a few years when all the CI/CD and orhestration is integrated and commoditized.

So while you are “waiting a few years”, the company has new problems to solve write now. So no you can’t stick around using VB6 for the next 20 years.

yep and I'm pretty sure creating a crapload of devops scripts to support microservices will be the next problem you give the business.

If you are creating a bunch of “dev op scripts”, you’re doing it wrong.

I wrote one parameterized Cloud Formation template that creates our build pipeline for any new service. Most of the time we can use the prebuilt Docker containers (maintained by AWS) for our build environment. We have one or two bespoke Docker containers for special snowflake builds.

And if you haven’t read my other posts, and I get accused of being young and inexperienced, let me just say that my first “internet based application” used the Gopher protocol....

I haven't read any of your other posts and my comments were not directed to you in particular. You're really making my point. If cloud formation templates work then great. I don't know its limitations. I do know that kubernetes has become a standard for orchestration and that it becomes easier over time to manage. A couple years ago there was no support from AWS so maybe not the time to jump in. Likewise with Kafka. Cool tech but really expensive to manage. Now AWS and Confluent will manage so the costs have come way down.

It's really easy with AWS....

https://aws.amazon.com/about-aws/whats-new/2019/02/deploy-a-...

But we really don't care about the lock in boogeyman. Out of all of a typical business's risk, lock in is the least of them. We use lambda where feasible, Fargate (serverless Docker) when necessary. Why waste time doing the "undifferentiated heavy lifting"?

I would rather hire someone with that mindset. They are more likely to be interested in solving the actual business problems. The junior guy excited about frameworks and fads, is much more likely to create complexity (usually from vast numbers of dependencies and inappropriate technology choices). The flip side of course is that if you already have a mess, then the junior guy might be a better choice to maintain it.

I wouldn’t be excited at all hiring someone whose skillset is ten years out of date. It tells me a lot about their lack of willingness to keep up with technology.

This depends on what you mean by "technology". I would expect them to be aware of emerging trends in the industry. Bonus points also for an interest in the latest computer science. But I don't care if they haven't hacked on groovy gradle scripts or injected Spring AOP pointcuts into Java beans. This sort of tech is accidental ad-hoc complexity and not progress.

It’s not about “emerging trends” but they should be familiar with a chosen technology stack that is in the “plateau of productivity” in the hype cycle.

Spring's AOP pointcuts (in its first incarnation as AspectJ) and Groovy (pre-Gradle and pre-Apache) are both over 15 yrs old. To not know those is having a skillset that's well over ten years out of date.

Heck, I know what those are and I've only written 20 lines of production Java code. They came up repeatedly when I was researching using Microsoft's (now defunct) Unity framework to do AOP in C#.

https://github.com/BitsCorner/AOP-UnityInterceptor

No, you can learn programming languages at quite a deep level in just a few weeks. I went from having never written or read a single line of Scala or Java in my life to making production critical commits to a customer-facing product in about two weeks, where the commits involved needing to know a lot about Scala case class patterns, some tricky in-house implicits, structural typing and the numerical package Breeze. The thing is, because I have developed deep skills at delivering software products in other languages, I know what questions to ask. I know to look into build tooling, certain design patterns, ask what is the equivalent of foo from language X over in language Y. Experience allows you to short circuit huge chunks of the learning process and make bigger strides to knowing complete functional units of the language and tooling. Yes, you’ll keep learning more after a month, but in all sincerity, if you’ve learned at least one procedural language very deeply and have at least brushed up against other paradigms and design patterns, then you can learn almost any other language, whether it’s C++ or Scala or Rust or Haskell or Fortran or Erlang or anything else... up to about an “advanced intermediate” level in just a few weeks of self-teaching.

There is no monolithic "modern tech" to keep up with. If you think there is, you work in a bubble and don't have nearly enough experience to say anything intelligent about how to hire senior developers.

Moreover, if you're proud of how hard it is to learn ins and outs of your tech stack, you're likely using a shitty tech stack and costing your company tons of money.

That’s true. No one is saying be good at everything. But you should be surveying your local market, seeing what an in demand tech stack looks like and align your skills with it and have a cohesive story to tell.

But you can’t be proficient at an architectural level with a stack in two weeks no matter how good you are.

Would you say that you could me an iOS/Android developer in two weeks just because you picked up Swift/Java?

> ASP.NET WebForms app running on IIS, ... Go microservice running in Kubernetes and using Kafka

Those things don't really count as languages, they appear to be a mix of development environments, software packages and architectures. Learning these things is critical and hard but there is a key mitigating factor. That factor is that really what needs to be learned is 'how we do things around here' which is typically company specific and needs to be learned by a new hire anyway.

My experience suggest new hires in cognitive roles (at medium-large businesses) take 1-2 years to get to the point where they can be proactively useful, purely from learning who is who, what the corporate history is, what ahs been tried before, why things are what they are and what their role's problem domain is really intended to be by their boss. Compared to that set-up time, the cost of knowing or not-knowing a technology is quite small.

> This whole "learn a new one in a couple weeks" mindset is toxic and needs to die.

It is true though. Learning a new programming language to the point you can write bug-free code and execute someone else's design is really easy. Learning how to solve a new problem is typically the hard part.

I 'learned' Python in 2 weeks. What I write looks a lot like C code, and I didn't make great use of the standard libraries, but it works fine. Compared to that learning how to use a large new library for a new problem typically takes a months.

Not necessarily, except for maybe Go, those are industry standard technologies that you could find someone who knew and could add value almost immediately.

We are very heavily invested in the AWS ecosystem. The difference between hiring someone who has the same amount of useful development experience but no AWS experience and someone who does and how fast they can hit the ground running is stark.

Side note: saying my beliefs need to die as the first thing you ever said to me is pretty aggressive.

But to your actual comment: I'm learning new things all the time. My focus when I'm coding in my spare time is a simple IDE, some project management tools, and a simple game engine I am building. I learn new things in those projects literally every day.

I'm not going to do a bunch of hello world apps in random new "Pro" technologies. I did a lot of that in my 20s, it was fun and I was curious about them, but my interests have shifted.

There are enough jobs I can say "no" to the people who want only coders who are using the newest "Pro" toolset.

Honestly, a good hiring manager will realize you ideally want BOTH that person and people like me on a team. One person will know that Rails 7 solves our new problem, and the other will know that a simple refactor will save 30 hours of headscratching over the next year.

Why not? I’m older than you and I have passed plenty of technical interviews on the $latest_tech.

Sure you can learn a language in two weeks but a language is far more than syntax. There is the ecosysystem, frameworks, third party packages, etc.

And honestly, I would be more concerned about hiring someone who built their own bespoke framework from scratch than someone who used an existing one. Building frameworks rarely adds business value.

> And honestly, I would be more concerned about hiring someone who built their own bespoke framework from scratch than someone who used an existing one

It's almost like you're pretending the years between 2008-2012 never happened, but I'm sure that's not the case.

In 2008 I was in my mid 30s, had been working at one job for nine years as a C/C++ bit twiddler and writing COM/DCOM objects that interop’d with VB - in other words I had a skillset they was woefully out of date. I got lucky and found a job that let me pivot into being a modern “enterprise developer” and barely survived rounds of layoffs for the next three years.

I learned my lesson. For the last 10 years I’ve kept my resume competitive with whatever the $cool_kids technology is and haven’t had a problem competing in the market.

What are you referring to?

Ditto, if something extremely special happened in the years 2008-2012 with regard to frameworks, its cataclysmic significance seems to have escaped my notice. Rails? /shrugs

I think maybe they are just referring to the fact that in that era pretty much everyone had to build their own "framework" to get a big web app up, because there weren't a lot of established choices.

Between 2008-2012 there was ASP.Net Web Forms and MVC was becoming popular.

I didn’t play in the Java space back then but there were plenty of Java frameworks (https://dzone.com/articles/what-serverside-java-web-framewor...)

Ruby on Rails was released in 2005.

Knockout JS was introduced in 2010.

Django was released in 2005.

There was also Mojolicous for Perl also released in 2008.

This is what I meant, apologies for being cryptic. Web/JS development was absolute chaos, it just so happened that Facebook & Google won the day and we've converged on some "standards" in React/Vue/Angular, and I use that term very loosely.

The things I've seen. shudders

> And honestly, I would be more concerned about hiring someone who built their own bespoke framework from scratch than someone who used an existing one. Building frameworks rarely adds business value.

If I were interviewing such a candidate, I'd dig into why they built a custom framework. The answer to that question could be quite enlightening, especially if they mention business reasons for doing so, or if they talk about what they've learned since then.

When I started my own business a decade ago, I decided that existing web frameworks wouldn't suit my needs and built my own. Though I built a framework that suited my needs extremely well, it was a massive distraction from my actual business (which wasn't even tech). In interviews, I freely discuss how my NIH syndrome contributed to my inability to get the business off the ground; I've found that it tends to go over rather well with interviewers.

Same. The way I work at home is no way to run a business, and I am painfully aware of that fact.

I go to work to be on a team and pull in one direction and support the leadership and make hard compromises.

I write code at home to understand where the industry will be in 10 years.

Hum... My experience is that whatever framework a business use in any widespread manner, I do always have to build another one on top, because generalist libraries completely suck for productivity. Unless you are a single app shop, then you can just hard-code everything.

I don't get how improving development speed does not add business value.

It means that the next developer will have to learn your bespoke logging, authentication, etc. and other cross cutting concerns instead of just being able to go to stack overflow and finding an answer.

If their is a problem, they have to wait for a response from the one Guru who wrote it.

Most architects who think their problem is a special snowflake usually isn’t.

So you are against encoding domain knowledge in the software? It's better to re-invent the wheel with every application so that "the next developer" can google their questions?

Frameworks aren’t about domain knowledge. They are about cross cutting concerns. You can’t imagine how many badly written custom ORM, logging, authentication, web frameworks I’ve come across.

I don't grant your premise (that it's wheel-re-inventing), but yes: it's usually massively better to build with familiar, boring, transferrable, google-able tools. Even if it takes a little bit more time to build.

The point of personalizing a framework is that most developers shouldn't be thinking about logging, authentication, etc.

Again, my experience is that the personalization layer is very easy to get by a senior developer, maybe there is some unconscious architectural decision that is biasing it, but I've never seen one have problem taking my code. Junior developers by their turn just can't grasp it, what I consider a feature, they are better just using the functionality until they get some experience.

If it's "just logging" then of course just use the provided solution.

A custom domain for a business would be something more than logging though. For example, perhaps you want your logging to include some regulatory compliance hooks. Or maybe you want to do logging that also serves as a persistence layer for undo/redo and you need that to be tied deeply into your presentation layer.

In those cases it's much more than just "log this" that's being abstracted, it's all of the business needs around logging.

And next developer can't get away from learning all that code. Either it's tied up as a nice internal company logging framework, or it's spread out as a bunch of concerns through the app. But either way, the newbie has to figure it out.

I would presume he built his own as a learning exercise/for fun.

Given the amount of spaghetti I've seen... It's my understanding that being able to think in frameworks is a rare skill. If you find someone who is actually good at designing frameworks maybe, just maybe they have some real skill and they built their own framework to practice and hone their craft because that's a necessary condition for getting good at something?

Granted, I hear what you're saying, but I'm not convinced your blanket dismissal is the right analysis without digging deeper on the individual details.

> And honestly, I would be more concerned about hiring someone who built their own bespoke framework from scratch than someone who used an existing one

If they're over 45, then they likely worked in the late 90s and early 00s. If they were like many of us, then they worked on at least some web applications back then. This was far before jQuery and even Prototype.js on the frontend. Java, PHP and Perl were commonly used on the backend (or where I lived, more often IIS with asp). But the start of the career of someone in their 50s and even 45+ was before any commonly-used framework in open source scripting languages used for web development (unless you consider PHP to be a framework).

Even Spring framework was only created in 2003 (I just checked to confirm). Symfony in PHP was 2005. And those took several years to catch on in their respective ecosystems.

Tons of companies had in-house frameworks back then. Who did you think wrote them?

Even if someone working back then never explicitly built a framework, they used design patterns that mirror today's frameworks. If not, they were writing spaghetti code (and to be fair, that was pretty common back then).

Based on your username and your assertion ("older than you"), you're what, 45? Have you forgotten what it was like back then?

In the late 90s early 2000s every website was a bunch of spaghetti code with a mix of code and html - the original VB based active server pages, JSP, or even ugly Perl and PHP.

But when he said he “made his own web frameworks”, I’m assuming he was talking about this decade.

> But when he said he “made his own web frameworks”, I’m assuming he was talking about this decade.

I re-read the comment in question. Not sure why you would have assumed that. Someone who is now 37 likely started programming before the age of web frameworks.

No, your parent was correct. I am currently building a complete web application hosting toolkit that I started in earnest in 2015. I worked on it this week.

I wouldn't call it a framework, because it's built of small independent pieces, but it's a similar scope to something like Rails.

I did start coding long before web frameworks existed though. :)

> a language is far more than syntax. There is the ecosysystem, frameworks, third party packages, etc.

Agreed. However, if you're a software company you've already likely made all of those decisions. If I come work for you, I'm stuck with them. It doesn't matter if I like the package manager or the frameworks. That's just the background against which we work.

Our work is making our lives better, and solving the company's problems to the best of our ability, given all those constraints.

> honestly, I would be more concerned about hiring someone who built their own bespoke framework from scratch

Yes! I feel honestly quite nervous about sharing that aspect of my work, because I worry people will see me as out of touch.

But I am quite up front that I don't advocate using my toolkit in production environments. My professional advice is usually quite conservative. I tend to advocate for minimal disruption and using standard tools as they were meant to be used.

However, because I do that all day at work, I see all the cracks and warts in the architecture and when I go home I want to work on the future.

And even though you are correct "building a framework rarely adds business value"... that's not what motivates me. I do think there is value being created, and I will eventually be able to cash in on that. But I am doing it because I am interested in the future, and I want to work on tools that transcend the pointless busywork I have to deal with day to day, in the name of meeting quarterly goals (which TBF is crucially important in a business context).

I get direct enjoyment from working in my own little hobby world where those constraints don't exist, and that is enough motivation for me.

Let’s say you learn C# in “two weeks”. Is that going to be enough time to get proficient with ASP.Net MVC? Entity Framewor? IIS? The built in logging framework? The DI framework? Middleware? What if they are using Xamarin for mobile? Let’s say you did pick up Xamarin (which I haven’t).

Would you know the fiddly bits about doing multithreaded processing with desktop apps using Windows Forms?

As a 40+ yo dev I want to agree with you but:

>I've forgotten more frameworks than most coders will ever learn.

Forgotten knowledge is worthless

> I mostly don't care about programming languages, they're roughly the same and I can learn a new one in a couple weeks.

I used to think that, its possibly true, but the platform that comes with the language certainly can't be learnt in a couple of weeks so I dont think this is true as it used to be.

> I know technologies like Rails and SQL, but I don't play with the new toys as much as I used to, becuase lately I would rather solve a new problem or build a new tool than learn a new tool.

This is a real problem for you if companies are hiring for people that know the new toys.

> It's another world, and a lot of companies just don't bother...Thankfully I have no desire to work at any of those companies...There are plenty of companies trying to hire people to solve actual problems

That's great now, but in the future the job market might not be so tight and then people with your attitude might find it really tough.

I think the point on forgotten frame works / new tech is -- nothing is _really_ new. Knowing ten web frameworks inside out isn't really 10x more than knowing one, because they have a tremendous amount of overlap. Relatedly, I've forgotten how a couple frameworks work because there's nothing interesting left behind, that isn't present in the newer ones. I'm quite sure if I had to go pick one back up, it would look very familiar. perhaps I know more about it now than I did when I "knew" it.

Great, but that means that for the "knowing frameworks" box, there is no advantage in hiring an experience dev over a younger one.

The general thrust of this thread is that there is no advantage in hiring an experienced developer over a younger one.

You might be getting a mid-six-figure salary in your first job, but you probably ought to be socking it away because you can't expect raises.

You didn’t work with a C# ASP.Net WebForm dev who before that was a WinForm dev trying to grok ASP.Net MVC.

> Forgotten knowledge is worthless

Not really, you pick up something you forget much faster than something you've never seen before. It's all in there somewhere.

Learn a language in a couple of weeks? No way! A couple of weeks is plenty to understand the mechanics of the language, but the biggest aspect of a language is the library.

I do agree that testing for the ability to solve problem is hard and gets neglected.

If at 37 you consider yourself "older programmer", the industry is fucked. The minimum social security retirement age in US is 62. That is older programmer. Full retirement age is 66.

"Why is that old guy still working? Must not have worked hard enough like I do! I'll be retired at 45 from my stock options and 401k" e.g. extrapolating from last 5-10 years of stock returns, which is all they've known...

> I can learn a new one in a couple weeks.

To play devil's (or manager's) advocate - have you ever crunched the numbers on what it takes to pay you for a couple of weeks? That's not a trivial investment, especially considering the risk that you just thought you could learn a new language in a couple of weeks but were wrong.

Sure, but you also have to weigh that against what it takes to pay people to develop the wrong architecture at the wrong time, and the opportunity cost to the company as a whole to be saddled with those bad decisions. That's not trivial, either.

(although I agree with the sibling comment — one doesn't really learn most languages in a few weeks)

Well let me tell you the story about some older experienced “infrastructure consultants” who thought that AWS was just like on prem infrastructure, did a lift and shift, moved my former company “to the cloud” and ended up costing more because they thought they had “learned AWS”.

Architecture and processes that was fine for one environment was horrible for the other.

In development terms, you can write FORTRAN in any language.

Let’s not talk about the one Java developer who thought he could pick up C in two or three weeks. It was ugly.

But during that time, they're not just learning the new language, they're also learning your environment, applications, and tools, which they have to spend anyway. In my opinion, that could accelerate their learning of the language, by seeing it used "for real", rather than in a more restricted tutorial context.

Every job I've ever worked I felt I produced more cash value for the owners than I took. I'm actually quite proud of that fact. It's important to me, and it's one of the things I think about all the time as I'm making decisions on how to work.

Isn’t the whole point of asking programmers to work out and and write code for alien dictionary from Leetcode to test their problem solving ability? There are really no easy answers to interviewing people for jobs, I guess.

Yeah, I'm talking about people being upset that I had to look up the syntax for ActiveRecord associations because I haven't written any in a while.

> But how do you evaluate a coder on their ability to solve problems? Much harder.

With an IQ test, the same way you evaluate anyone else on their ability to solve problems.

That evaluates a person on how well they solve IQ test problems.

It evaluates the quality of the substrate.

Having a high IQ doesn't mean you are going to be able to hit the ground running, solving problems and writing production code in your first week.

Better to hire for your particular skills. And younger is cheaper.

Reply on news.ycombinator.com