Not targeting you, but the industry in general. In every other industry I've been in outside of software dev, 10 years is not considered elder. You're just now becoming not a greenhorn. You're just now getting your sea legs. It's amazing what additional experience happens after year 10.

To that effect, Rust (2015) is 9 years old, Go and Node are 15 years old. While Python (1991) is 33 years old. Just putting things in a different perspective

▲

shermantanktop 2 years ago | parent | next [-]

I’ve been in this game for 30 and I agree with GP. “I won’t build that simple thing from scratch, I’ll just import this thing that does approximately what I want.”

We should banish the word “import” in favor of “take a dependency on someone else’s code, including the stability of the API, the support model, willingness to take patches, testing philosophy…”

Reputation is a rough proxy; inspecting the code can help. But when the thing you built your house of cards on falls over, you often can’t fix your house, and have to build a new house.

Obviously this applies more to utility code than it does to entire languages. But even there, Apple has broken their Swift syntax enough to release tools that upgrade your code for you…and that’s the best case scenario.

▲

hnlmorg 2 years ago | parent | prev | next [-]

I’ve been in the industry for > 20 years and if anything, I think most people are too scared or lazy to reinvent code.

I’m not suggesting the earlier argument about NIH (not invented here) syndrome doesn’t exist. But I’ve certainly never seen in the scale that the earlier posted claimed. If anything, I see people getting less inclined to reinvent things because there’s so much code already out there.

But maybe this is a domain specific problem? There does seem to be a new JavaScript frontend framework released every week.

▲

YZF 2 years ago | parent [-]

I've been in the industry for >30 years ;)

I'm not sure what's the proposal?

- Don't use an OS. Write your own. Linux? Boring.

- Design your own CPU.

- ext3 or xfs? Nah write your own.

- Write your own database.

- Ethernet. Too boring. Create a new physical layer for networking.

- Naturally create your own programming language. That'll make it much easier to find people when you have to expand the team.

Seriously, build vs. buy and NIH has always been with us. There's a time to build and there's a time to buy/reuse. Where are you adding value? What's good enough for your project? What's strategic vs. tactical? How easy is it to change your mind down the road? What are the technical capabilities of the team? How do different options impact your schedule/costs? How do they impact quality? In the short term? In the medium term? In the long term.

	▲	ATMLOTTOBEER 2 years ago \| parent \| next [-]
		I’ve been in software for over 40 years (yes I’m that old ), and in my humble opinion it’s always correct to build. It keeps things fresh.
	▲	spookie 2 years ago \| parent \| prev \| next [-]
		Let's be honest, nobody is saying to rebuild the world from scratch. The stance for in-house built tools and software is a much more balanced act than that. One that prioritises self-reliance, and foments institutional knowledge while assessing the risks of making that one more thing in-house. It promotes a culture where employees stay, because they know they might be able to create great impact. It also has the potential to cut down the fat of a lot of money being spent on third parties. Let's be real, most companies have built Empire State Buildings out of cards. Their devs spend most of their time fixing obtuse problems they don't understand, and I'm not talking about programming, but in their build processes and dependency hell. It's no wonder that the giants of today, who have survived multiple crisis, are the ones who took the risk of listening to those "novice" enthusiastic engineers. Don't kill the enthusiasm, tame it.
	▲	ConspiracyFact 2 years ago \| parent \| prev \| next [-]
		This is a bit disingenuous, don't you think? There's technically a spectrum from low-level to high-level code, but in practice it's not too difficult to set a limit on how far down the stack you're willing to go while building. Writing a new testing framework is qualitatively different from writing a new OS or filesystem, and you know it just as well as everyone else does.
	▲	yellowapple 2 years ago \| parent \| prev [-]
		"If you wish to make an apple pie from scratch, you must first invent the universe."

▲

Cthulhu_ 2 years ago | parent | prev | next [-]

It just feels different in software development because things have moved very fast, I'd say especially when github rose to prominence. The amount of software developers on the market has also increased exponentially since then, so the amount of (relatively) junior developers is much higher than those of 15, 20+ years of experience.

▲

jltsiren 2 years ago | parent [-]

The number of software developers has maybe doubled in the last 20 years. The number of senior developers has "always" been low, because the field suffers from unusually high attrition. Many people find that software is not for them, many switch fields after losing their jobs in an economic downturn, some move to management, and some make too much money to bother continuing until retirement age.

	▲	samatman 2 years ago \| parent \| next [-]
		I'm reasonably sure that this estimate is far off the mark. The numbers I've seen suggest that the number of new software developers entering the industry has doubled every five years since at least the mid 90s. That's not the same metric as total number of developers, but it may as well be, and it definitely doesn't add up to a mere doubling of the total in twenty years.
	▲	mrkeen 2 years ago \| parent \| prev [-]
		Has there actually been attrition? Exponential growth is enough to explain "many more juniors than seniors" at any time in the past, present or future. Also for attrition to be the cause, you'd need a lot more seniors dropping off than juniors.

▲

WalterBright 2 years ago | parent | prev | next [-]

It often takes 10 years or more of use before you discover that your technique is execrable.

For example, most use of macros, especially when you invent your own language implemented as macros.

▲

WalterBright 2 years ago | parent [-]

A lot of people disagree with me on that. Wait till they try to get other people to understand their code :-/

Me, I've eliminated nearly all the use of macros from my old C code that is still around. The code is better.

I suspect that heavy use of macros is why Lisp has never become mainstream.

	▲	kazinator 2 years ago \| parent [-]
		Heavy use of macros could be why C went mainstream. Macros gave C efficient inline functions without anything having to be done in the compiler. Doing things like "#define velocity(p) (p)->velocity" would instantly give a rudimentary C compiler with no inline functions a performance advantage over a crappy Pascal or Modula compiler with no inline functions, while keeping the code abstract. And of course #if and #ifdef greatly help with situations where C does not live up to its poorly deserved portability reputation. In languages without #ifdef, you would have to clone an entire source file and write it differently for another platform, which would cause a proliferation due to minor differences (e.g. among Unixes). Ah, speaking of which; C's #ifdef allowed everyone to have their own incompatible flavor of Unix with its own different API's and header files, yet get the same programs working. An operating system based on a language without preprocessing would have hopelessly fragmented if treated the same way, or else stagnated due to discouraging local development. Thanks in part to macros, Lisp people were similarly able to use each other code (or at least ideas) in spite of working on different dialects at different sites.

▲

jrk 2 years ago | parent | prev | next [-]

Rust was started in 2006 and launched publicly, I believe, in 2009, the same year as Go. The point stands that these are still fairly new, but it’s not nearly that new.

▲

ChrisSD 2 years ago | parent | next [-]

Rust 1.0 was released in 2015 making it almost ten years old.

Rust, unlike Go, was largely developed in public. It also changed significantly between it's initial design and 1.0 so it feels like "cheating" to count pre-release versions.

Still, a decade is a significant milestone.

	▲	ternaryoperator 2 years ago \| parent [-]
		That's right. One of the knocks on those early versions was that every new release broke previous code in significant ways. Which is one reason that v. 1.0 was so important to the community. They could finally commit code using a stable language.

▲

cmrdporcupine 2 years ago | parent | prev [-]

Early Rust was a very different beast.

But could say the same about Python pre-1995 or so.

My biggest problems with Rust, though, are Cargo and Crates.io, not the language.

	▲	dhosek 2 years ago \| parent \| next [-]
		Weird, cargo and crates.io is why I ended up deciding on Rust for developing finl rather than C++. The lack of standardized build/dependency management in C++ was a major pain point.
	▲	anacrolix 2 years ago \| parent \| prev \| next [-]
		crates and cargo are better than Rust actual
	▲	gary_0 2 years ago \| parent \| prev [-]
		Cargo and crates.io are something C/C++ developers would kill for (which is why cargo is what it is, I think).

▲

roenxi 2 years ago | parent | prev [-]

Well "elders" are the people who have been there for the most amount of time, so if the industry has >30 year veterans wandering around then the elders will have around that much experience. But the learning in an industry is generally logarithmic where most of the lessons get picked up in the first 1-3 years and then after that there are only occasional new things to pick up.

If anything software seems to be unusually favourable to experience because the first 5 years of learning how to think like a computer is so punishing.