Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

> It is visible in this article - the Haskell community is trying to convince this guy that he needs to know a wall of jargon from a relatively obscure branch of maths in order to program effectively. They may or may not be correct, but it is going to be a while before his attention makes it to the task at hand.

This seems to be the core problem in the communities, like you said: a tendency to believe that time spent learning the language or learning concepts or fighting with libraries or struggling with documentation doesn’t actually “count” towards time spent getting the job done.

I think this plays into our tendency to view learning and education as investments rather than costs. That may be true on a personal level when using your own time, but using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.

View on HN

> using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.

As kindly as I can put it: I’d argue that within this sentiment are the foundations of everything wrong with the ecosystem of professional software engineering.

Let’s start with, if you don’t let people learn on the job, you have to have at least 20% annual turnover to be only 5 years behind the knowledge curve.

At 10% turnover, you’re 10 years behind. Managers think people shouldn’t be learning on company time, HR tells the board lower turnover is a goal.

Inevitable next step is pausing all productive work to undertake a “Digital Transformation™” to try to replace 20 years of old tech. But the firm won’t know how.

>> using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.

> As kindly as I can put it: I’d argue that within this sentiment are the foundations of everything wrong with the ecosystem of professional software engineering.

Almost all Software Engineering, as practiced, is not a form of engineering in any way. Many times Software Engineering is really a bunch of commodity workers, who are learning, assembling commodity components that don't really work, under the oversight of a more senior developer who helps everything not fall apart.

You might be interested to read Hillel Wayne's crossover project, where he interviewed a number of people who had worked in traditional engineering roles as well as in software development.

https://www.hillelwayne.com/post/are-we-really-engineers/

The upshot is that "engineering" isn't the paragon of excellence we like to think it is. Whether or not you agree, it's a good read!

Thanks!

> Let’s start with, if you don’t let people learn on the job…

Learning in the job is great, within reason.

Abandoning all of your existing experience and trying to write new projects in a completely unfamiliar language with zero prior experience is not reasonable, though.

Learning isn’t a binary yes/no feature of a job. There is ample room for learning without allowing reckless decisions like trying to use Elm for server-side code when even the Elm authors are hostile to such a use case.

It’s pretty clear that these numbers are made up. Software engineering is an incredibly multi-dimensional field, and it is not a fact that learning on the job is beneficial to anyone let alone employers. And you assume so many things that will not always be true, like the fact that everything will always be changing in the field.

You may feel different, which is ok, but don’t bring made up numbers into it.

> using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.

It's in fact very cool. I get to take those skills with me when I leave in a few years :)

> using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.

To defend the counterpoint, artificial scarcity is abundant in the industry. Deadlines always approach, projects are already late. If employees don’t learn and improve on the job, employers will be happy to replace them.

I think this problem is specific to the Haskell community. No one's going to tell a brand-new Clojurist that they need to learn about reducers.

Agreed. Clojure is the most productive language I've ever used.

> This seems to be the core problem in the communities, like you said: a tendency to believe that time spent learning the language or learning concepts or fighting with libraries or struggling with documentation doesn’t actually “count” towards time spent getting the job done.

Well... if you learn them on this project, they don't count for the next project. So in that sense, if it levels up your group, then you only pay the price once, but you reap the benefit for a long time.

For purposes of any one project, though... the time counts as overhead. It needs to pay off, or it's a waste.

>using your employer’s time to experiment with difficult new concepts and languages when you have a deadline approaching (or long since past) is not cool.

Boss makes a dollar, I make a dime, that's why I learn zygohistomorphic prepromorphisms on company time.

Reply on news.ycombinator.com