Hacker News Reader

Comment by lnsru | Hacker News Reader

I don’t think, somebody needs old programmers. Look from business perspective: there is no difference how polished code base is. Younger folks can develop the same product with lower salaries than grown ups. Yes, they will look for greener grass, or do some crazy things, but business gets same output at lower cost. I am experiencing this at my current workplace. It is desired, that people leave after few years and freshmen can be hired again. Experience has zero value in business context.

View on HN

This is the classic naive perspective. To a serious extent, experience tells you what to build and when. The actual building is quite often better to farm out to someone who can be bothered to trawl through familiarity with the latest 5-minute javascript framework. That is why successful founders tend to be middle aged[0]: they know when not to waste resources, and to use the right tool for the job. That tool might be you.

Furious activity is no substitute for understanding. - H. H. Williams

... via https://github.com/globalcitizen/taoup

[0] https://theconversation.com/most-successful-entrepreneurs-ar...

You are hoping they actually build what you told them to - from bitter experience.

Actually that's not true. Experience does matter. In one particular class I took we implemented a simple marching cubes implementation, or rather I did because the rest of the class could not complete it. I had about 8 years of experience in graphics type programming at that point.

People stupidly think programming is applying the most common patterns to the most popular frameworks. That is one type of programming inexperienced young people do. More typically it requires some strong domain knowledge. For instance one particular system I worked on was mostly written by one person who obviously had a lot of experience in the field. I think the younger programmers complained for many many years about the implementation, but none of them could have written it. This person had to ignore everyone else, who he knew were complaining without any experience to back it up, to get it done.

> Experience has zero value in business context.

I wish you luck fundraising.

Luckily I am in industrial electronics without a smallest chance of fundraising.

You must have a different definition what is "business context". In business context, it's all about selling your ideas and making money for the business - even as an industrial electronics.

In this case I see business context as a cost structure of my current employer. I clash almost everyday against big bookkeeper army of the big Corp. Their view is very primitive: engineer costs money, they don’t differentiate by experience, age, capabilities. Even mythical 10x engineer (there is one in the whole floor!) is just another row in excel. Technical people often overlook the fact, that organizations are run by bookkeepers and so called business people. They have no background to judge technical development. If they can sell code written by freshmen, why should they hires bunch of experienced and expensive experts?

Awesome comment. When you become old you’ll then be talking about the value of experience and how that makes business sense. You’ll switch because you think exclusively in terms of self interest.

I am already graybeard. I had eye opening moments looking for a job right before pandemic. Now I desperately want to produce some rental real estate and leave engineering.

> there is no difference how polished code base is

There is no difference how maintainable the code base is?

I've seen a very well-known business, which is regularly discussed on HN to grind to a halt and fall behind all of it's competitors in a very fast-growing and fast-moving space because it was built on a ugly spaghetti monolith developed by someone with PhD in history and almost no experience in engineering. And that's only the first of many examples I can think of.

Could you, please, elaborate more about that ugly spaghetti monolith? I have similar situation at work. Maintainability is hard to measure, so my every try to measure and improve stuff ends with words “not a business case”.

If you're looking for help fixing the mess you are dealing with, find the book Working Effectively with Legacy Code - https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe....

You might also want to read Refactoring to Patterns, but the legacy book is more important to start with.

Then learn their language and phrase your suggestions in ways that expose the issues to them in terms they understand. This requires you to fully understand what is important, and what is not important, to the business.

Oh, and you should get good at incremental refactorings, and at downscoping your improvements so that they become feasible and easy to sell. Or even not require any selling as they can be done as part of normal work. It is not the big rewrites that get done, it is the small improvements that take only a little time, so learn how to compound them.

By the way, getting good at the above points will over time also change your own priorities.

But is it really my duty to play managers, so they are ok with refactoring and improvements? I imagined somehow, that management and developers have same goals and it’s natural thing having clean codebase and up to date electronics.

Yes, it is your duty to make them understand. Especially if they don't have a background in development themselves.

Also I would not frame it as playing them. That is the wrong mindset. You should be among for a high level of trust from their side and then playing them can backfire.

It depends on the work and the caliber of talent. It also depends on the state of the organization. Some fields require specialized skills, and experience is highly valuable. Programmer is broad term. Not everyone is building crud apps.

Inexperienced people can build small orgs into business crippling holes.

Unless they fuck up - for example a botched site migration that causes massive losses and ends up mentioned in the financial pages.

A number of UK banks have had disasters TSB, Santander caused by not having enough older more experienced developers.

To be fair - the example of the UK banks who had disasters was because the systems in question were usually old 'legacy' systems that were being slowly replaced by new tech and newer developers. It was a lack of developers with experience of those particular legacy systems when something went wrong that was the problem, rather than the lack of older developers with more experience of development in general.

Reply on news.ycombinator.com