Hacker News Reader

Comment by shados | Hacker News Reader

Good points. I feel software engineering as a field is growing a lot slower than it could, for a couple of reason.

The first is what you mention: everyone ignores lessons from the past and try to relearn everything from scratch, reinventing the wheel and best practices over and over and over, making the same mistakes again and again. Some communities also heavily encourages concepts like how experience doesn't matter, best practices aren't a thing, etc.

The second (and part of the reason the first is a thing), is the amount of people acting as experts that really aren't. Even big names and pseudo-celebrities in the field frequently have no idea what they're talking about. Once people realize this, they start questioning everything.

And thus, we're stuck in software engineering stone age. Being unable to separate the good stuff from the bullshit is holding us back a lot.

View on HN

May I add to this with a third: difficulty in creating a strong system of mentoring?

Many companies have a formal mentorship program but it is often in name only (at least in my experience at 3 companies).

In a formalized apprentice program, a worker can feel okay about not knowing things and asking the person for whom they are apprenticing. Despite formal mentors, I believe many junior devs do not have a person that they feel comfortable not knowing things. Moreover, plenty of senior engineers do not make good mentors (either don't want to or don't have the strongest of communication and mentoring skills).

You'll have a crop of engineers with 0-2 years experience that don't feel comfortable not knowing something because they feel it can be a sign of technical weakness. Perfectly valid questions go unasked and a young engineer may spend 3-4 days trying to answer something that his mentor could help him/her with in 15 minutes.

Great knowledge isn't transferred optimally in this scenario.

Oh man, I relate to this feeling tremendously. I am a junior dev on an apprentice program (just shy of 1 years experience to date) and the times I have struggled with something because I let my pride, or fear of bothering people with inane questions, have been the lowest points in the last year. I always get to the otherside wishing I just talked to a senior dev - because more likely they could have saved me a stressful week.

For whatever it might be worth, here is my advice to juniors about being mentored:

It mostly is true that the only stupid question is the one you didn’t ask.

Please don’t ask the exact same question twice. Take notes if you need to. Asking for clarification or following up for more detail is fine.

If you have many questions and your mentor has other responsibilities, try not to keep interrupting them all the time. Discuss the best way to balance your needs and theirs, perhaps finding a time/place/medium where you can have a larger discussion and deal with several questions at once.

Assuming your mentor has accepted that responsibility voluntarily, they’ll probably be happy to help even with the basic stuff — we all had to start somewhere — but will appreciate it not taking over their whole day.

Also - make sure they understand your goals instead of your hyperspecific question - a lot of time can be saved by avoiding the XY problem.

http://xyproblem.info/

Few random thoughts as someone who mentored many junior engineers:

- don’t care about your pride. You’re here to learn, so do everything you can to learn. Imagine even the worst possible scenario - people get fed up with you - you’ll go and find different job (benefits of being in a booming industry). Your old coworkers won’t follow you but knowledge will

- don’t think about all the time you spent looking for answers yourself as wasted. Some if it was, but you learnt also tons of other things that may not be relevant now, but will be in a future

- ask your mentors not only for direct answers to your questions but also for reason and/or how they came to that conclusion. Most important skill for you to learn is how to think about problems and how to find solutions, not the actual solutions to few problems you came across

In my experience people with great knowledge generally have an urge to pass it on and they appreciate self initiative taken by the person learning. I have mentored a few people during my job and generally feel that my time was wasted only if they don't take initiative to learn themselves. Many a times I leave a crucial thing out of the answer and ask them to try to find for themselves as teaching is not about giving a ride but showing the way.

During the years I have found that it's not helpful to go into too much detail when teaching, as the people who are just starting won't be able to appreciate it and it may actually overwhelm them.

> In my experience people with great knowledge generally have an urge to pass it on and they appreciate self initiative taken by the person learning.

I wish my personal experience was the same, but it has been the polar opposite. In my current and previous roles, there is always too much work, which causes management to pressure development for deliverables, which results in juniors getting pushed aside. It's a terrible cycle and I have no idea how to improve it.

This is not necessarily the opposite. It is perfectly possible that the knowledgeable people you've worked with actually wanted to pass it on. They just weren't given the time to do it.

You should be angry about overtight deadlines and companies who live by those, not to the actual people. This also points to a possible solution for you: switch companies.

It's much worse than 3-4 days of wasted effort. A bad design can get so baked in it's nearly impossible to correct.

As a counterpoint to that, in some cases technology is changing so rapidly that things which were best practices no longer are and vice versa. Things that we take for granted now, like CI/CD, were not even technically possible 20 years ago. If people weren't constantly challenging best practices as new technology came out then we'd still be pushing our CRs through change acceptance boards.

Or think about "the cloud," "infrastructure as code," "immutable infrastructure," all that stuff that's considered best practices now couldn't have even been conceived of when we were spinning up new servers by driving to the data center and dropping a new 1U in the rack.

Good point, absolutely! The line is really thin between industry changing stuff (CI, cloud, distributed version control, type systems that don't suck, etc) and reinventing the wheel through arrogance or just not knowing any better (yet another testing framework, screwing up some well studied patterns :cough Java Optionals cough:)

The graybeards among us might chuckle at the thought of calling it "distributed version control" when the CI system requires a centralized copy of the repository acting as a source of truth in order to work.

CI systems only need the "centralized" copy as a reference point of what the current master is. Everyone gets their own entire copy of that repository though. If the truth suddenly changes it's known. I also know that if the copy in the "centralized" matches my own then the CI is also running exactly my code. If the centralized machine fails I can fail it over to any copy on any machine. That seems pretty distributed to me as compared to the original "distributed" version: e-mailing source code around. Version control like SVN and CVS were centralized in that me having a copy of the source and you having a copy of the source indicated nothing about whose version is correct. Moreover a failure of the central spot in the system is fatal unless you had backups as a form of pseudo-distribution whereas in today's version control a failure on any one machine is irrelevant to the preservation of the system.

I'd add to that the predilection for hiring young engineers and overlooking older ones. While it's true that older ones can get stuck in past practices, they also recognize things that have been tried before, seem like good ideas, but just don't work for non-obvious reasons.

For example, implicit declaration of variables in programming languages.

A strong team will have a mix of older and younger engineers.

Language design is its own thing with its own body of knowledge and experience. Of course, often times new languages were designed by those who could engineer their compilers and interpreted, leading to lots of mistakes that would be more apparent to a seasoned language designer.

Mentorship at the highest level (principle to senior and below) is desperately lacking. I vow myself when I reach that level to pass it along the best I can, but something I desperately searched for when I was starting.

I pair programmed for 3 months (which I consider apprenticeship / live action mentorship) with someone who was a way better engineer than me at my first "career job" out of college. I learned more in those 3 months about software engineering than in my previous two.

> I vow myself when I reach that level to pass it along the best I can, but something I desperately searched for when I was starting.

Mentoring is one of my favorite thing. Finding people who want to be mentored is...challenging though. Probably a chicken and the egg (one of the other posters mention how people are put in a situation where they can't be open about not knowing things), but so many entry level engineers just pretend they know everything.

Completely agree with you though that this kind of dynamic would drastically improve the industry.

This is a salient point. I've personally found that most junior/intermediate people want to be mentored but it should always be done carefully and with consideration. I've had a couple of junior/intermediates, though, who, like you are saying, just did not want it. I think that most of them have moved on from the company but there is 1 person who is still around and who is now the type of person who has 5 years of experience but it's all the same year.

I'm writing the book on senior+/lead to junior/intermediate mentoring with my company. I've been floating my notes and mentoring guidelines around the department heads and other leads. I love it, personally. Department heads and managers see the value but are reluctant when they see that I'm willing to spend months with a junior or that I might myself out there for hours a week with an intermediate. If I come across a particular interesting performance problem, or something like that that is challenging and requires a certain type of experience to get into, I'll schedule time to pair with 1-3 of my team members on it so that they can hopefully benefit from the experience. The real challenge, though, is that not everyone wants to mentor. I personally think that it's critical and a core part of my responsibility but most of the other senior+/leads where I work are not engaging in much meaningful mentorship with their teams.

> I learned more in those 3 months about software engineering than in my previous two.

Do you mean you learned more than you did in 2 months of school? Did you drop "years" as the last word? Did you mean it wasn't a great experience because you could have learned what you did in 2 months instead of 3?

Part of the Stone Age is that the good stuff is already out there in books nobody reads, rather than fancy Medium posts.

Do you have any book recommendations?

Yes.

This is only one of these "must-read book list", what you can do is search several of them and see which ones are quoted by almost everyone!

About "everything" I would rate the following books very highly, for their sheer usefulness:

- Thinking Fast and Slow (really do the exercises!)

- then Neuroleadership which describes the purpose of brain structures, it's somehow wider than kahneman

- A Mind for Numbers (include very useful data points for knowledge workers)

- Distinction: A Social Critique of the Judgement of Taste

- Cutting Through Spiritual Materialism

About programming I would rate the following books highly, but at the same time it seems a bit fruitless to me to read about programming, rather than spending more time reading about psychology or sociology:

- the Economics of Software Quality

- Peopleware

- Pragmatic programmer

- Mythical Man month

^you'll see that these books are hardly kept secret, it's just that people quote them but don't actually read them, or so it seems.

Do you happen to have a list of such books off the top of your head?

https://news.ycombinator.com/item?id=20043965

Part of the problem is the concept that programming is "engineering". It explicitly is not, it doesn't have a defined set of criteria for evaluating design or ensuring results.

"Doing Agile" doesn't qualify as "engineering", CMMI level <5 isn't engineering. Even CMMI level 5 is only engineering in a very small domain. Most shops claiming CMMI level 5 are only qualified in one particular aspect of software development.

So we're still in the "master/apprentice" and "journeyman guild" days of our profession. But Universities and Colleges are desperate to sell their 4 year "software engineering" degrees, so cover up the lack of rigor with a mountain of bullshit.

So the first step to really establish software development as an engineering discipline is to stop fooling ourselves. Being able to "refactor my FactoryManagerFactory class" is not engineering.

When a programmer has to sign off and take liability for any failures like a PE does on a bridge is when we'll be able to say we are "engineers" with a straight face.

I would argue that we have people who already are software engineers. People who know the machine their code is running on very well, and use this knowledge to fully optimize for that specific machine (embedded, console development).

They take what they are given, and engineer a solution that fits that piece of hardware as well as possible. No bullshit FactoryManagerFactory.

Reply on news.ycombinator.com