Systems thinking as important as ever for new coders | Hacker News Reader

Systems thinking as important as ever for new coders

hanselman.com

191 pointsadamflanagan32 comments

Systems thinking is, by far, my favorite mode of thinking. It's why I love programming, business, biology, mathematics, aerospace, etc... I'm convinced that being able to think about abstract systems fluidly is a core skill that separates the good from great in many fields and this is probably more so true in software. I really wish there were better resources for building up this skill set. I was gifted with a decent intuition for it and gained a lot from engineering courses, but I just haven't found anything specific that I can point a junior engineer towards and say "This, this is the essence of systems thinking!". The closest thing I've found is a lecture series on the space shuttle design[0], and while the series is fantastic, it doesn't focus on the core idea of systems thinking. Does anyone have any useful resources or recommendations on the subject?

[0] https://ocw.mit.edu/courses/aeronautics-and-astronautics/16-...

Alan Kay has spent a long time thinking about how to teach systems thinking to children (etoys, kadema,etc). Hopefully he sees this question (he sometimes posts as alan-1)

There's a newsletter online called Resilience Roundup which, to a limited degree, covers these topics extremely well.

I have found "Thinking in Systems" [0] to be a good book for crystallizing "systems" concepts in abstract. For example, it includes discussions on feedback loops, bottlenecks, equilibrium, etc.

IIRC, it has been used as a textbook for systems theory classes in some universities, but it's concise and written for a general audience.

[0] https://www.amazon.com/dp/1603580557

Teaching based on an older framework still will require learning the basics of the language, basics of analysis and design. As long as the course is well structured and well taught, the students should become empowered enough to aquire the updated knowledge for the newer framework.

Would it be better to base the course on the up-to-date flavor? Yes, if resources allow that. However,the emphasis should still be on developing a mindset that is motivated for extended learning.

Frameworks change, domains change. Learning the basics of a framework will not guarantee a job, learning how to solve problems using whatever combination of frameworks will prepare one better for a career. After all, a perfect entry level is a practical learner.

> Would it be better to base the course on the up-to-date flavor? Yes, if resources allow that.

I'm not so sure. Java is a popular language both in industry and for teaching, but I'm glad they taught us the ancient and unpopular Common Lisp first.

When you know Common Lisp, you're well prepared for most of the Amazing New Features that slowly trickle into Java, since Common Lisp already had most of them.

Well said. I have come across candidates looking for engineering positions with a laundry list of fancy technologies they claim to have have worked on — yet can’t answer simplest questions about the fundamentals — way too often for my liking. There seems to be an inherent assumption that one just needs to be able to operate the newfangled technology of the day to be an engineer. Who needs to know about how network calls are made or the mechanics of spawning processes/threads — there are libraries to abstract all that.

It makes sense though. Think about how our education system typically works. Memorize these identities and recite them off, you'll do fine. Learning is a checklist, not a process. Your collecting facts, not tools.

To address this problem we need to implement real changes to schooling, starting as early as elementary school.

I agree — and it’s not the new graduates. I have come across people with a couple of years (sometimes more) under their belts.

Folks with just a few years experience are very much still new.

> Know what artifacts your system makes and what's needed for it to run. Know what kinds of things its good at and what it's bad at - in a non-zealous and non-egotistical way.

It's hard to remain objective when deciding what technology to use. The programming language you know can usually the most suitable; as you have the most experience in it, despite better alternatives which might be available.

The disheartening reality is that there's always a better system for your application...

True and sometimes you have to decide whether the time spent learning new language and development is better or worse than just using the language you know well.

It's one of the reasons I'm learning Kotlin, I know sometime in the next year I'll need it.

At least someone on the team should know where the landmines and Booby traps are in the language before you plan a big project on it.

If you find out how many and what kind they are after you have gotten half way to the goal then you might have to start over.

There's a pretty big principle-agent problem for these kinds of decisions, too. Choosing a programming language has an effect on the implementing employees' resume strength, not just on the end result that they provide for the company.

A symptom of this is having a startup that uses more programming languages in production code than programmers.

Objectivity is a false idol - as is perfection.

No matter how much research you do, or how wise you are, you still have to decide how to measure "best." And that's inherently subjective.

This is a great way to think about it when you're looking for good candidates. Most everyone with a CS degree knows the general systems knowledge. But, most interviewers aren't going to hire someone with general systems knowledge, when they can get someone who knows the exact technology stack they're working on.

Err no.. I disagree. I’d rather hire someone with strong fundamentals but with minimal knowledge of the stack over someone who can cobble together a solution using the stack/framework but has unclear fundamentals.

In my computer engineering program, we spent a lot of time talking about concepts and theory and less on the implementations of them. For example, in my database class, we spent a lot of time learning about relational calculus and less (almost no) time on writing SQL queries.

We studied CLR and spent more time using C++ as a way to understand the algorithms and reason about them and less time learning and mastering C++ specifically.

Isn't this the case at most universities or bootcamps? I guess I can see why someone would ask the questions the student asked Scott judging by the way new technologies are spoken about here and on the internet in general. There is an intense amount of FOMO as a developer that's hard to stave off even though concepts truly travel.

I simply can't imagine how you spent time learning about relational calculus without performing some of it.

No it is not the case at most universities (I can't speak for bootcamps, though I wouldn't be surprised to hear a greater variance and overall lower average in this area for them).

There are always different teaching/learning styles, but everyone agrees you need to practice to learn. A course about databases without writing SQL, is like driving a car without the wheels.

Easy, relational calculus is a theoretical model, you don't even need a computer to understand it!

Might help those who are looking for reference material, a recent discussion on "Mental Models" — https://news.ycombinator.com/item?id=19895407

As a developer who is looking to better my understanding of system thinking, are there any books/courses you recommend reading to help begin thinking in this manner.

Systemantics/The Systems Bible, by John Gall, for a lighthearted, whimsical introduction through real-world examples across a range of industries. An Introduction to General Systems Thinking, by Gerald Weinberg, for a more rigorous/structured introduction.

I've heard good things about Donella Meadows, but I haven't read anything of hers yet.

Thinking In Systems by Donella Meadows is great.

Isn't that a different kind of "Systems Thinking"? This one is about feedback loops.

Hanselmanns is about operating systems stuff.

If you really want to start learning about systems, go for Incose's setup: https://www.incose.org/

You might find some of their handbooks online free of charge (maybe not the one most up-to-date).

There is a really good book written by Haberfellner called 'Systems Engineering' which to my knowledge is only available in German. The book is awesome though: https://www.amazon.de/Systems-Engineering-Grundlagen-Reinhar...

Oh, it seems like they finally managed to get it translated - apparently available in July this year: https://www.jpc.de/jpcng/books/detail/-/art/reinhard-haberfe...

I did my Master's degree in Systems Engineering based on both Haberfellner and Incose's handbook. It's been great learnings which have been useful ever since helping me to separate all kinds of problems as both a software developer and a systems architect.

So, enough said - separate and conquer ;)

There was a recent Ask HN here[1] asking just that. Some of the suggestions overlap with what others have provided here, but it may be useful.

[1] https://news.ycombinator.com/item?id=19133097

Is there a simple introduction, a few few pages that will help me at least identify "systems thinking" when I see it?

Right now I keep hearing that "systems thinking" is a good idea, but I could not tell it apart from regular thinking.

I've seen some definitions that are vague and circular: e.g. "systems thinking deals with thinking about systems" but there must be more to it than use of the word "system"

Just a random thought - could there be a point, where system thinking is not feasible due to the size of the system?

At that point, one might as well start mentally breaking down the Larger System into smaller Sub Systems and the Contracts between them.

In fact, this is the distilled essence of software engineering, as I understand it.

You also start to approach the old UNIX command line philosophy. Each command did roughly one thing very well and input and output were pretty simple CHAR streams.

Reply on news.ycombinator.com