Hacker News Reader

Comment by austincheney | Hacker News Reader

The most consistent pattern I have observed as an older developer with some years on a resume is absolute utter astonishment when I don't want to waste time on a bunch of confused newb shit like sickly bloated frameworks with a million dependencies. Its weird to hear people acknowledge that I have just so much experience on paper and yet be so amazingly dumbfounded surprised that I would be focused on less junior things.

I haven't yet found the proper words to converse through that, but a team of similarly older developers sharing similar concerns adds tremendous value.

View on HN

omg yes. i've taken way to many jobs where, after alot of very considered discussion about the kind of work i do, and how I dont consider generic devops worth the time. happy to debug our code in production, but i'm not first line support or software install/configure.

yes, they assure me, they really want a software developer in the classic sense. this is an absolutely perfect fit.

and when I show up? welcome to the team, why dont you shadow joe who is going to be upgrading Kafka kafka this week.. at Google they actually pointed me at the nightly error queue for some AI pipeline and told me my job for the next 6 months was going to be pulling out the errors and manually fixing the input until it passes.

the real issue is that they just dont really do software development. so much so they dont even know what it looks like.

"the real issue is that they just dont really do software development. "

No offense, that kind of seems to be your issue, not theirs.

In large orgs if there are 10 'technical but not really dev roles' for ever 2 devs ... that's the reality of the world we live in.

It's maybe 'sad' that we call can't write code, but that's maybe not quite an 'industry' problem.

On the other hand, using giant fragile stacks with a million dependencies and systems that are an 'inherent mess' ... well that's maybe a little bit different and motivation is different because you might be actually wasting your time.

But in reality there is a ton of work to be done and most of it is not glamorous.

sounds like you would be wise not to hire me. if only more people understood that software development isn't operations.

As an engineer with more than 15 years professional experience, my definition of "junior shit" would be thinking you can hand-roll a foundation or framework better than something that already exists.

It's number 39. in Akin's Laws of Spacecraft Design.

https://spacecraft.ssl.umd.edu/akins_laws.html

I have this on my list of questions I ask interviewers. I should follow-up with "how much of your budget is dedicated to this?" Major red flag if they don't even know how much catering to their NIH syndrome currently costs them.

Really great list, thanks for sharing that!

Number 4 hits too close to home. Great list.

Do you also ask the opposite? How much of your budget is dedicated to working round, debugging, and wrestling with tools developed for the framework?

That reminds me of people comparing writing in JavaScript (without their pet abstraction library) to writing in assembly. What a bunch of horse shit. It’s a red flag to self-identify configuration monkeys (people limited to following instructions) apart from those that can actually write and test applications.

This rule about absolute failure in rolling your own realistically only applies to cryptography, because the bar there is set extremely high and there is a rigorous vetting process.

I mean you put it a bit harshly but I'm with you. Last year I delivered an app in vanilla JS (super tight deadline and couldn't figure out how the google maps / react integration worked). It was fine. I rolled my own reactive data structure in a few lines of code (seriously, it can be less than 10) and got to work. Really enjoyable experience. Felt so much closer to the browser and didn't feel like I was suffering a big loss in expressiveness.

I've been doing some more vanilla JS recently in my off time. The only thing that really makes me wish for a library is IndexedDB - by the time I took JS seriously it already had promises, and this oldschool callback heavy 'onerror' style is a challenge.

I often come to this conclusion.

One of my frameworks has hundreds of open source contributors now, and tens of millions of downstream users use things built on top of it.

I'm now working on another one, and we just had our first few PRs from people who aren't me.

And I ain't too young anymore.

(And yes, this comment, while true, is tongue-in-cheek; there were darned good reasons for making new frameworks in both cases)

Backend framework? Fair enough. Frontend framework? I'm really not so sure anymore.

    user does something -> change state -> modify DOM

This isn't exactly rocket science.

DOM modifications can get very slow very soon. After all, each reflow is actually a whole cascade of operations.

Ostensibly simple things like swapping rows in a table can be computationally intensive if not done right.

It's a fruitless endeavor arguing with people who think frontend is trivial. They've only worked on small, isolated projects by themselves and have used that experience to convince them it's the whole story and captures every project.

> It's a fruitless endeavor arguing with people

Agreed :D

Oh absolutely. You need to know what you're doing.

But they same applies to react.

If the existing framework is so great, why does it keep getting replaced with a new framework? Why aren’t we all still on Angular?

And if we all keep hiring only the best candidates, why would we think that they can’t write a better framework? somebody is writing a better framework.

> As an engineer with more than 15 years professional experience, my definition of "junior shit" would be thinking you can hand-roll a foundation or framework better than something that already exists.

You're not wrong, although to be fair, it isn't always about hand-rolling a framework. Sometimes it's just about experience and knowledge about which existing framework might best fit a given use case (without unnecessary bloat) as opposed to just choosing the latest "ooh shiny!" bloated buzzword framework to build upon purely because it's new and trendy this week.

Although some use cases do call for the "bloated" framework, because feature requirements demand using a framework that provides those features. Again, experience and knowledge can inform whether this is necessarily the case, and one should obviously avoid hiring any applicant who does not see a valid need for the choice of framework/toolchain when it was chosen for good reason.

The most senior engineer I’ve met had a refreshing attitude that clicked with me.

“It’s just typing. Typey typey type.”

I take that to mean, no matter the code base, no matter the questionable choices made historically and that will be made in the future, the job doesn’t change.

Figure out the requirements, grind until they’re met.

Who cares what the stack is and how many layers of libraries there are? If that becomes a problem we will fix it.

But how much typing, how much staring at screens, how many meetings are needed to reach your actual goals? I care about the choices bc the wrong ones create problems which require more typing, or typing at night. "The job doesn't change" except the amount of time and effort required to do something useful can change.

Sure, but that’s not my problem as a new hire. I just assume any new codebase will be horribly sticky and hope I can smooth it out a little.

Humans calibrate so quickly. With my latest job, I spent the first month thinking I was coding my way through a nostril-deep vat of honey and getting nothing done, but my boss was impressed with my productivity. Now it’s just normal and I feel productive again though the pace hasn’t changed.

Startups go faster, big companies go slower. I’d much rather get paid well and navigate intractable tech debt with zero pressure to work extra hours than move quickly and get side eyes for stopping at 5.

> how many meetings are needed to reach your actual goals?

Basically zero, other than requirements gathering meetings with customers, the number of which are required is independent of tech stack.

Other meetings will probably happen due to process choices made by your org, but they mostly don’t (1) depend on tech stack, or (2) contribute to reaching the actual goals, except insofar as they are necessary to clear arbitrary impediments also created by organizational process decisions.

> I care about the choices bc the wrong ones create problems which require more typing, or typing at night.

Unreasonable working hour demands are not a product of tech stack choices, they are a product of management disrespect for staff.

You cannot avoid them by choosing the right tech stack.

>Who cares what the stack is and how many layers of libraries there are?

Exactly.

Can I get on with this person who will be my boss and these other people who I will sit next to for eight hours a day? Do I prefer JavaScript or Python?

One of those questions is much more important than the other.

I'm not even that old, but a pattern I noticed when I've interviewed in the past couple years is that maybe I'm applying for the wrong jobs because my would-be peers ask questions that seem irrelevant and seem confused that I don't have answers ready for "what frameworks do you use? Which languages do you like? etc.", but then I get in an interview with someone who would be above me and we have a great chat about architecture and design and things that are actually relevant.

I'm here to build a house, I want to talk about the architecture of structural design of it. I don't care what brand air nailer you guys use.

I have the exact same experience. Many would-be peers simply don't get it when I have very little interest in the type of framework or language they use. They take it as a sign that I cannot contribute to the team readily even though they acknowledge I have more experience.

My company has a kind of cultural disease where everyone aspires to be an architecture astronaut, people with an ounce of talent or ambition learn to treat code as beneath them, consequently we get beautiful design docs and a garbage codebase. For that reason I would fail any candidate who displayed this attitude. I expect senior candidates to raise the bar on quality and craftsmanship in implementation, and I’ve met plenty who do. YMMV.

I don’t think being a framework partisan is a particularly good sign, but at least it shows you have some experience and reflection and taste with regard to the tensions involved in making things that run.

I'm one of four engineers at my company. I don't have the luxury of offloading my job to someone else. Also I really feel like you're projecting attitudes that I (at least didn't mean to) portray. I design the dog food, and then I make the dog food.

I'm also an old fogey. When anyone says claims they or their title is "software architect", it usually means they're full of shit. The best "software architects" I've ever known typically call themselves programmers.

> The best "software architects" I've ever known typically call themselves programmers.

Or "hackers", but then you gotta resort to "ageism" in order to discern if they're actually a real old-school hacker or a modern wannabe hacker "script kiddie". ;)

Ecosystem matters a lot. For example, React might be overkill for a lot of projects but it’s relatively easy to hire for and there are a lot of drop-in tools and components available.

The lunatics took over the asylum long ago.

I think the sane are locked up in the asylum these days, and the loonies are in the spotlight.

What frameworks do you like?

Not sure what kind of work you do but whenever I hear frontend devs don't use a framework/view library I have a difficult time taking them seriously. More often than not that means they're using some mess of a pseudo-framework that they created themselves.

When you now have things like TypeScript that allow you to define interfaces completely external from your logic you have already addressed half of what frameworks solve for without writing a single line of code. After that the only things left that frameworks provide are APIs and composition. If you know what you are doing you define your APIs first in consideration for the business logic and save composition for the final step after all other logic is written. Then you can make any adjustments to your internal APIs as necessary to glue things together. No framework is needed, minimal refactoring, and a smaller code base with less complexity because a generic framework doesn’t know your business requirements in advance.

Reply on news.ycombinator.com