Hacker News Reader

Comment by xwdv | Hacker News Reader

There’s a certain amount of ladder kicking involved in telling people to choose boring and beige technologies after you started up your career chasing after new and exciting shiny things.

Every developer should spend some time working at the bleeding edge, so they know how it feels to get cut. The best time is absolutely at the beginning, when you’re a fresh grad and have the energy. You have the rest of your life to work on boring stuff that pays the bills, and who knows, if you are successful with a new technology early on, you might just be working on it for a very long time, continually breaking new grounds.

Choose bold technology early, then boring.

View on HN

The problem is that those people who chose shiny new technology only see the benefit, while all the others in the company will rot in hell because of the stupid choice of a junior engineer (who jumped ships 3 times meanwhile). I don't see how does that benefit the company? The whole point of the article is that you should make wise technology decisions which benefits the whole organization.

> The problem is that those people who chose shiny new technology only see the benefit, while all the others in the company will rot in hell because of the stupid choice of a junior engineer (who jumped ships 3 times meanwhile). I don't see how does that benefit the company? The whole point of the article is that you should make wise technology decisions which benefits the whole organization.

Sure, if your interests are closely aligned with the company. But as you noted, the junior engineer jumped ships 3 times already, probably with significant salary increase each time, and in part due to a CV that includes the use of exciting modern tech, which shows he's eager to learn and is passionate etc. Why would he care how the old company is doing?

People often don't stay at the same place long enough to feel the long-term consequences.

People will do whatever the (job) market rewards and is fun.

It's a bit different when you wear multiple hats. Then it may be best to focus on one specialization and keep things boring for the rest. For example at a small company, as a single-person data scientist/engineer/developer you may want to focus less on the IT fads and more on the modeling, because your CV is best padded by fancy new ML models, not by fancy new database engines. Or vice versa.

> Why would he care how the old company is doing?

Because at one point one recruiter or HR manager will ask him to provide a reference from his previous manager? And when he looks like an absolute ass he can pad his resume with whatever he wants? Short time thinking will not get rewards in the long run in that case.

Yeah but what are the chances that someone from the hiring team will call an old reference and get told the story about how said developer's shiny thing chasing caused them a lot of pain? What are the chances that the developer gets a big raise from the new job because he has experience with a desirable shiny new technology?

The reason we have this phenomenon is that companies highly value (or even overvalue) experience with hot new technologies. So even if as a developer you know that maybe kubernetes, microservices, and NoSQL [or whatever it is] are not right for your organization, you know that having those on your resume will help you get a big raise and a promotion on the next job. The chances that your new tech chasing misadventures will haunt you in future jobs is very low.

True, this puts the onus on the CTO not the junior developer who will make lots of dumb choices, not just shiny-chasing.

But there's no reason you can't work a day-job doing boring technology and do fun stuff on your side projects.

Companies should actively support your side-projects, especially if they involve R&D experimentation that could be useful in the long run to the company. Whether that's paying for you to attend educational events or any books/online video courses/supporting SaaS services/etc or giving you 10-20% of your week to do what you want.

There are too many CTOs and senior developers out there who are too busy working on their pet projects to care.

The foremost role of senior devs (at least in a company with juniors and mid-levels) should be technical oversight. Set up the architecture, set standards, and do the code reviews.

Not sit in the corner and learn React.js.

Why would anyone pay a senior developer $100-200k+ to sit in a corner and learn React.js?

I was talking about junior devs making (predictable) bad choices not senior devs. Your senior developer should know better than to shiny chase and value delivery over cute technology, otherwise he's not a senior developer.

Some startups can't afford a senior developer or simply don't know any better... but even junior can pump out working apps. Then it's just up to the next evolution round when you build a professional team instead of some cowboys.

> Sure, if your interests are closely aligned with the company. But as you noted, the junior engineer jumped ships 3 times already, probably with significant salary increase each time, and in part due to a CV that includes the use of exciting modern tech, which shows he's eager to learn and is passionate etc. Why would he care how the old company is doing?

Sounds to me like this is an endorsement of hiring less-shiny candidates who have been at their previous employers for longer rather than the shiny candidate who keeps jumping ship every time.

Once upon a time, there was value seen in the weird concept of "professionalism."

> while all the others in the company will rot in hell because of the stupid choice of a junior engineer

If a team's management can't prevent this from happening, then they've got bigger problems to worry about.

True. But some people will do everything (including ruining team morale) to play with their new shiny toy and it's usually easier to ruin that than taking steps for prevention. But you are generally right.

>But some people will do everything (including ruining team morale) to play with their new shiny toy

Because everyone has different interest/goal. The interest/goal of junior developer is different than the senior developer, even though both working in the same company.

It might very well be in their best interest for the junior develop to play with shiny toy, if that the case then that is what they should do.

While for the senior developer though it might be in their best interest to prevent that.

Yes, this. At my last job, I was a mid-level developer. I set up a dev ops pipeline. I moved a bunch of stuff to microservices. I did a whole bunch of other shiny things. It looks great on my resume.

Microservices were a mistake. I should have fixed the underlying problem with the DB (we were misusing the ORM) first. It's fixed now, but we still have to deal with debugging microservices which sometimes mysteriously fail.

There's a whole bunch of other cruft I sprinkled throughout the codebase. Good news is I left with good experience, because I made a few mistakes. Bad news is they still have that architecture.

That's why you always need a senior developer on deck to tell young whippersnappers like me "no" every so often.

Increasingly, I'm understanding the benefit of working on projects outside of work -- so you can make mistakes like that on your own time. I wish more people followed the Google model and gave you every Friday to mess around with your own projects.

I wished Google followed the Google model, because I work there.

20% projects are still technically a thing, but not many engineers actually have one.

For NDK users that is what it feels like, a 20% project from Android team, given how slow it progresses.

It only took them 10 years to fix the header file mess.

Surely what you state here can be said of any advice given due to experience. As long as the natural inclinations of younger developers push up against said advice, it's completely sane to give it. Because without it, young developers will have an incomplete mental model, and will lack the intellectual tools to potentially make better choices early in their career.

Also it seems to miss the point somewhat: choosing 'boring' technology has little to do with working on things that are unfulfilling. On the contrary, when tech stack choices are the thing from which developers derive their excitement from, in my view, it's often "empty calories" masking the lack of "emotional nutrition" they are getting from the problem they are solving or the users they are serving. For every whiz-bang neural network getting users to click on ads, there's a 'boring' embedded system running on an ancient C framework somewhere putting satellites in space. I'd rather work on the latter any day of the week.

As Hamming said, "if you're not working on the most important problem in your field, why not?"

Because my family need feeding and housing.

I gather your response here is meant to be a retort to the idea that you should be working on the most important ideas in your field, or that the question by Hamming implies some sort of judgement if you are not. That's not the point of the question. The point of the question is for you to reflect on the reasons you are not, as a means to helping you guide your future choices insofar as working on things that are important matter to you. (Which for some, may be not important at all.)

Many people do not reflect on the reasons they work on the things they work on, or on the weight they give to the import of the problems they are solving, and so need such a question to be asked to help them to understand their needs, motives, and goals. When I first read the question I was in a situation where yes, I had financial needs that were pre-conditions for a job, but I failed to recognize the degree of choice I had over the problem space or system I was working in with regards to focusing on problems I cared about solving (or, more commonly, avoiding working on problems I considered meaningless or superficial.)

The problem is actually finding jobs where the problem itself (rather than the tech stack) is compelling. Personally, I haven't seen much of that outside of academia or the elite of the elite Google X type roles.

I freelanced for a guy who ran a cabinet factory, helping him integrate his automated fabrication equipment with his customer ordering system. Dead boring old technology, but extremely interesting to me learning about wood-working and stuff.

I don't know if I have a point, but I bet if you're not picky about tech stack (at ALL), you can find some really cool work to do in non-tech industries.

Isn't it a bit silly to presuppose that what we have now is the best we are ever going to get. I mean, files were state of the art at one point, but i don't think anyone will suggest we go back to punchcards.

"Boring Technology" is the wrong thing to aim for. Aim for simplicity.

Which JavaScript framework is the simple one?

Mithril? https://mithril.js.org/

The downsides might be (I'm guessing) performance for very complex apps and lack of pre-built third-party components.

There is definitely a spectrum of simplicity among the frameworks. Angular seems to sit on the opposite side of the spectrum. It has many benefits, I'm sure, but in every aspect they've chosen the more complicated solution.

The simplest is the one that doesn't exist ;)

That is: you're presupposing that a JavaScript framework is actually necessary in the first place. I'd argue that the whole concept of a JS framework is the epitome of chasing after shiny and complicated things. If instead you start with just plain ol' HTML and incrementally add CSS and JS as actually needed, you're much more likely to end up with a much simpler and more maintainable end result (or, at the very least, you will have figured out the actual and specific reasons why you might need the additional complexity of, say, Sass or this week's JS framework).

VanillaJS!

But seriously while Svelte is the new kid on the block, they do claim to have minimal API design and no virtual DOM. So I guess the real answer is Svelte.

It does have a compiler, though. So compared to the old-fashioned JavaScript workflow it adds a mandatory build step. And I don't think it would work with languages that compile to JS – or does it?

So much this! I mean the author also worked for 7 years at Etsy which did ship quite a lot of new things (bad and good). For me this is similar to telling a 20 year old, dont go out, stay home, watch tv you will less likely get injured.

The problem is that a lot of shiny new technology is not cutting edge, nor bold. It's just new, and often done more poorly than boring old technology. Also, for someone fresh out of school, you should understand what the status quo is capable otherwise you can't possibly understand what a new technology is really offering.

There's a difference between bold technology and new technology.

A lot of new tech is shiny and provides legitimately useful benefits. Think the new wave of frameworks that started with Rails and Django.

There's a lot of shiny tech that has been a gigantic waste of everyone's time, like MongoDB and people trying to shoehorn MapReduce into every possible computation.

I feel like that's terrible advice for a fresh grad. If they keep getting cut early on, they will lose confidence and start doubting every decision they make, losing motivation to work on anything and burn out.

If they are always overruled when they want to try something new, they will also lose confidence and motivation.

The interesting thing here is that I find many young engineers want to work on the newest tech, however, they also want the 10-5 schedule.

If you want to work on new and exciting, you have to be willing to own the consequences and stay up late digging into the bugs, learning the ins and outs, and committing to delivering what you said would be delivered. </endrant>

TLDR: If you want to work on interesting, it'll take more commitment.

Reply on news.ycombinator.com