The challenges of teaching software engineering
sicpers.info
sicpers.info
Analog example I used (explain like they're five): Front end, backend, middleware, databases are like a Macy's animated window display. HTML is choice and order of the mannequins in the window. CSS are the colors and positioning. Javascript is the string that makes visible characters move. Middleware (Python, Go, Java) are the sales clerks grabbing goods from the warehouse (database), serving customers, and updating the window panes.
The course did a lecture on HTML/CSS first day, Javascript second, dug in deeper by debugging a snakes game in JS, Git on day 3 (failed for same reasons you mentioned), Ruby on Rails (immediate productivity was key), Wordpress installation, then PHP deeper dive, etc. One student said "I can't believe I paid someone $20k to build me a Wordpress site that I can now set up and customize myself after a few days."
Always start with immediate productivity for non CS students - let them sink teeth into the ideal outcome, then modify that ideal, then learn how to break and fix it, then dig deeper into why and how things work before going to best practices. If they don't know why something broke, they can always go back to figure out how it should work first.
Edit - also a favourite interview question for anyone that claims to be familiar with svn is "what does the switch command do", a quick and easy filter to seperate those that know from those that claim to know.
I'm ashamed to admit it, but I ended up copying the files just like everyone else on that project for the brief stint I worked on it. :(
If this were a class on git I might agree with you but Im in the business, not the classroom so it's all about time to productivity for me.
Split the other stuff like git, databases, OOP, functional programming, machine learning my God, for another course. There is no way anyone taking this course will get anything from this, it will just be a confusing mess of information that is quickly forgotten.
Then I saw it was four days.
It is very easy to overwhelm software students when trying to teach a broad array of topics (especially in a week!). He mentioned that his students ran into challenges such as not understanding the difference between 'python foo.py' and 'python3 foo.py'. How can you expect these students to overcome these beginner challenges and then still learn topics such as git, CI, machine learning (!!), functional programming, concurrency, processes, etc!
These topics can take years to learn properly, and require a good foundation. Maybe I didn't understand the purpose of this course, but it seems pretty insane
Wouldn't your audience be far better served if you offered dozens of focused sprint classes (1 topic; 1 hour) rather than some sort of eclectic marathon?
Design, testing, and debugging (which takes up more resources than writing code) require skill in forming good hypothesis and methodical way to test that hypothesis.
These type of courses should be designed more towards those skill sets than just learning to write code.
I would actually add to the above though that I think it's important people learn to approach problem-solving from a mathematical perspective. Unfortunately, a lot of people that get into software engineering don't like math, and they would generally be averse to learning about software engineering this way, but I think a lot of bad code gets written because the person writing it didn't approach the problem with the right structure or rigor.
A parallel to this would be something like, "You built a bird house out of wood. We'll teach you how to build a skyscraper in a week." It's just not possible.
I don't think people who go there expect to come out as experienced engineers. They expect to learn some this so that they can learn more later.
The amount of practical learning accelerated my first few years as a full-time developer. Went from barely using nix to spending nearly all my time there except for time spent in Outlook. Went from a cursory knowledge of C++ to having a beyond intermediate knowledge. Learned Python (back at version 2.2!).
I think a big point of a course like this is not to give you a full knowledge of the domain, but rather how to learn* about the domain. Software is constantly changing; to be effective, you have to be able to keep up. Which means a lot of reading. When I first started, Google wasn't a thing. Meant a lot of dead tree edition books (ebooks weren't a thing yet). I got my starting points when I was in high school from early forums and mailing lists circa 1995. Took a long time to research things at 56kbps. Also took an effort to convince my parents to buy me programming books at $40 a pop even in the 90s, but when they saw me reading them cover to cover instead of watching TV (easy to get motivated - we only had 2 TV channels) and spending hours slaving away on the computer on programming instead of playing Civ 1, they were more willing to buy the books.
The course is intended to help these researchers to understand software design and collaborative tools like git to be more effective at writing code.
it seems like a really hard problem.
Making working computer systems---like a drawing program, or an Amazon deploy---can be really hard, or really simple. You can teach someone enough Python for fizzbuzz in twenty minutes. Teaching them enough...everything...to get a web version of fizzbuzz, that checks a database for the words (it might be "nargle" and "gargle" by user preference, after all), with a Python install that they manage, a postgres install that they manage, that they don't feel at a complete loss about if something goes wrong, and to collaborate with others on this...is another matter entirely.
I'm not one of those who believes programming ability is innate, but there are absolutely compounding effects that can certainly have basically the same effect. In retrospect, I thank my lucky stars for my 6th-grade computers class using HyperCard.
One thing that the students taught me that helps overcome some of these things is a site called https://repl.it/ . I stopped my plan, started using it, and taught the rest of the class using repl instead in order to focus on the concept I was trying to teach. Obviously, as a professional software engineer you need to know about git, command line, etc., but those aren't what software engineering is. They rarely excite new comers to the field. Using repl.it helped to get to the core ideas faster for people who don't really know as much.
I love repl.it too, of course! It's nice to have several great tools to choose from.
I see where you're coming from with your suggestion, but I think in practice it contributes to information overload and intimidation to a large part of the population.
... software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."
[0] https://en.wikipedia.org/wiki/Software_engineering#Controver...
The fact is, nobody can program, not when programming means building complex systems (pretty much anything bigger than 30kLoC) absolutely correctly. Not I, not you, not the late Prof. Dr. Dijkstra — nobody. We can't.
But we need to build these systems nonetheless. So, "how to program if you cannot" becomes an essential area of study.
Yes, it can be abused, but can so nearly every other programming construct. There are places where goto makes sense, such as error handling or breaking out of nested loops. I hate seeing a Boolean flag(s) being tracked for whether or not break out of nested loops. It's more typing and confuses the intent. Just goto the label following the nested loop.
Also, nearly any looping construct can be implented using a conditional goto, and if you go down to assembly, they almost universally are. Jumps are goto's by another name. I've seen exceptions used for control flow. Awful. It's about knowing the appropriate construct for the problem at hand.
I've seen do{...}while(false) used with conditional breaks to avoid use of goto in error handling and it's confusing as you're reading through an unfamiliar codebase to see abuse like that. As I'm reading through the code, I see the 'do' and I expect the code to loop, only to continue reading and find out it doesn't loop. Frustrating.
Dijkstra certainly wasn't arguing you should use trick like do{...}while(false) to avoid using the GOTO keyword.
The basic details of the system are described in a book called "System design from provably correct constructs: the beginnings of true software engineering" by James Martin (he mentions Hamilton in the references.)
In modern terms you work directly with an AST and the UI only permits modifications by operations that preserve the correctness of the AST. It eliminates all sources of bugs, and it was simple enough to teach normal people to use it with just some coaching.
Anyhow, that's "software engineering". The rest of us are just pushing text around in buffers and hoping it isn't broken. There are a few people using math to make software, and it works out really well (E.g. https://www.categoricaldata.net/), but mostly "software engineering" as it is usually used is an oxymoron.
Static analysis and safe refactoring tools are great, but they are certainly not going to protect you from implementing the wrong thing because you misunderstood the requirements or the environment; that's not possible even in principle. At best you can check for consistency (for example, consistency between a specification and its implementation).
With the caveat up front that I know nothing about this beyond what you have written: wouldn't this just catch compilation bugs? The compiler tells me if the blob of text I gave it is incorrect in terms of any syntax errors. Business logic bugs and accounting for bogus data seem more important to me.
You could still use it to write correct programs that did the wrong thing. In other words, it couldn't catch bugs that occur "between the keyboard and the chair".
FWIW the tech has a bit of a Wikipedia page now: https://en.wikipedia.org/wiki/Universal_Systems_Language but it doesn't seem very informative to me. YMMV
(But that also worked with Lisp+Emacs!
> programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
Consider:
1 + "two"
>>> 1 + "two"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
>> 1 + "two"
"1two"
> It eliminates all sources of bugs,
My problem is I've been trying to get traction on this for years and no one is interested. (Although type-checking is finally getting some love. It's not all doom and gloom out there.)
Most bugs could be prevented or eliminated automatically.† If we're not doing that then in what sense are we entitled to call ourselves "engineers"? (Just to bring it back around to the topic.) I mean, our bridges collapse all the time. This is not science?
†See Alice Pascal https://www.templetons.com/brad/alice.html
> In a syntax directed editor, you edit a program, not a piece of text. The editor works directly on the program as a tree -- matching the syntax trees by which the language is structured. The units you work with are not lines and chracters (sic) but terms, expressions, statements and blocks.
This is still just syntactic correctness, you can only enter syntactically-correct Pascal programs, no typos either, but I don't think it did type-checking or anything like that. But it illustrates my point that if you're typing text into an editor and hoping it correctly describes a computer program, you're doing it wrong.
Equating the most trivial kind of errors (which are caught by the compiler anyway) with "all sources of bugs" ignores the kind of bugs which are actually hard to prevent and might slip into production. But these are the kind of bugs developers are actually concerned about. Preventing editors from saving a file with a typo in it is a solution to a non-problem.
If you want to interest people in these ideas, you should show how it can solve real problems.
> The overwhelming impression is that the authors have had more experience than education.
Yes, Hamilton worked on the software which literally put a man on the moon. But apparently this is worthless to Dijkstra since they doesn't use the correct academic jargon.
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...
- - - -
You found Dijkstra's review. I'm a fan of his but the guy was hugely arrogant. IMO he craps on them pretty harshly.
I can kind of see where he's coming from, but "he doesn't get it" IMO. He misses the point (or maybe HOS sucked compared to what was later described in Martin's book...)
- - - -
FWIW, James Martin went on to write "System Design from Provably Correct Constructs: The Beginnings of True Software Engineering" which is where I learned about all this. I don't actually know much about HOS specifically, only what's in that book. If you're interested that's the thing to read.
- - - -
> So how does this prevent any bugs which aren't already prevented by the language?
The UI would not let the user enter syntactically nor semantically incorrect "trees".
In modern terms, if you had a syntax-oriented editor (like Alice Pascal) for a language with good type-checking I think you would have most of what HOS et. al. was or did. At the time of Apollo 11 (circa 1969), type-checking was barely a thing:
> In 1969 J. Roger Hindley extended this work and proved that their algorithm always inferred the most general type.
https://en.wikipedia.org/wiki/Type_inference#Hindley%E2%80%9...
- - - -
> Equating the most trivial kind of errors (which are caught by the compiler anyway) with "all sources of bugs" ignores the kind of bugs which are actually hard to prevent and might slip into production.
Yes, I know, sorry. I admitted that "all sources of bugs" was hyperbole. I was going for rhetorical effect.
> caught by the compiler anyway
First, why wait? If the errors cannot be committed in the first place surely that's better than detecting them only at compile-time?
Second, compilers didn't catch those errors back in the day. The whole reason Dr. Hamilton made up this stuff was because existing methods, tools, and technology would have crashed her spaceship.
> ignores the kind of bugs which are actually hard to prevent and might slip into production
Every moment saved by the machine is a moment the humans can use to prevent or detect the errors the machine can't detect automatically.
Here we are back to Dijksra. You know he only got a physical computer when his colleagues forced him to get a Mac so they could email him, eh?
He held, and I agree, that the kind of errors you're talking about do not happen while typing in the software. They occur "between the keyboard and the chair". If I may wiggle a little, I think of "bugs" as glitches in the machine, while the kind of errors you're talking about I think of as just "errors". But I know that's idiosyncratic, and that most people lump them together as just "bugs".
The only thing you can do about them is think clearly.
- - - -
The original question of this subthread was, "What is software engineering, anyway?"
My answer is, "What Margaret Hamilton did."
My point is that we have had tools that systematically eliminate sources of error. All automatically preventable bugs should be prevented (modulus economic consideration, but here costs would be trivial for automation of error prevention and the benefits and cost saving would be pretty high.)
Otherwise, calling ourselves "engineers" is pretty lame. IMO.
- - - -
> If you want to interest people in these ideas, you should show how it can solve real problems.
Real problems, eh? :-) Sending a spaceship to the moon? And getting it back? And no one died?
https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#PGNCS...
To be fair, I don't know to what degree J. Halcombe Laning's software was influenced by Hamilton. She's pictured next to the "software" section of the Apollo Guidance Computer Wikipedia article, but not mentioned.
> The design principles developed for the AGC by MIT Instrumentation Laboratory, directed in late 1960s by Charles Draper, became foundational to software engineering—particularly for the design of more reliable systems that relied on asynchronous software, priority scheduling, testing, and human-in-the-loop decision capability.[14] When the design requirements for the AGC were defined, necessary software and programming techniques did not exist so it had to be designed from scratch.
https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Softw...
- - - -
FWIW I suspect that these folks are going to be the coming cutting edge (of true software engineering): https://www.categoricaldata.net/ ... fallout from Applied Category Theory http://www.appliedcategorytheory.org/
So I guess this part of the vision have come to fruition. It is a solved problem. Great!
I just fundamentally disagree with your terminology. Calling syntax errors "bugs", and redefining actual bugs to "errors" does not help anybody. The bottom line is that the major challenges facing software development is not a prevalence of syntax errors.
Complexity in software proliferates faster than in any other discipline precisely because it is so easy to create and change. The difficulty is not in writing or editing a line of code, but in understanding how that line of code interacts with all the other code in the program. The essence of software engineering is building large systems in such a way that they are as easy to understand as possible.
I think after the 80s, engineering lost its meaning in computers because people could abstract the machine away and hodge-podge a lot of systems.
No need to carefully encode data, precompile addresses, state etc which would be similar to the dimensioning computations in physical systems.
ps: to extend the story, most engineered things have very carefully defined dimensions and limits which drives most things in the design. Max Wattage in your PSU will reflect in the gauge of wires, size of capacitors etc. A bit like choosing an arch when compiling.
I remember some threads in 2000s boards where some guys did talk about jobs like these in computing. They had said space and said cycles to work with, with that they could see what algorithm could compute the needs back against the limits. I found it especially interesting brain wise because you could "think" in hard figures, instead of glueing things without any idea what was really going on.
In the US, where engineer isn't as controlled a term as elsewhere, we use the term engineer for all kinds of roles. In, say, Canada, engineer means a professional engineer in one of the legally protected categories. You can't use engineer as a job title outside of those.
So if you're trying to talk about software engineering, imagine something horrible has happened with a system you were involved in designing (say, Therac-25). What what you need to know and do to be able to say that this failure should legally qualify as an "act of god"?
The controversy is due to human biases and stupidities.
–Russ Cox, GopherCon Singapore 2018
Designing/creating software.
Professional engineers in disciplines have to sign their name to their designs in fields such as electrical, mechanical, structural and civil engineering, and can be held personally liable, monetarily, losing their license, and perhaps at the extreme end, criminally liable.
Software "engineers" are not.
Licensed Professional Engineers are also bound by a code of ethics by the appropriate industrial organization. e.g. for electrical engineers, you're bound by the IEEE code of ethics, even if you dont practice in the field.
I'm a licensed electrical engineering intern (I've been a licensed EE intern for 16 years now), but work entirely with software; I've never worked as an EE, nor have I met the professional requirements to take the PE exam. I'm still professionally bound by the IEEE code of ethics. I have objected to certain "projects" over the years because of potential violations. I almost quit one job because I was being pressured to violate the code, but my boss was fired and the pressure disappeared.
Such a licensing and accountability doesn't exist in software "engineering".
That said, I do refer to myself as an engineer and not a developer, because, well, I am an engineer. I follow different practices than web developers because I work in finance and theres billions of dollars on the line if I fuck up. I also work at a firm that requires disclosure of any professional licenses and an attestation that you are in good standing with the governing body (which I am). Professional Engineer (Intern) its not on the list of options, so I always have to type it in, they're mostly looking for CPA types.
Physicians practiced medicine long before there were formal licenses (and long after for that matter...see 3rd world discount medical/dental).
> Such a licensing and accountability doesn't exist in software "engineering".
That's not 100% true. There's Cisco certification, PCI certification. There's no HIPAA certification, but violations can and do cost millions.
Nor is it true that other engineering disciplines always require certifications. You can be a happily employed mechanical engineer without sitting for the PE exam.
I digress...the whole thing is a red herring. The definition of a discipline exists independent of the whatever accreditation procedures happen to exist.
This included classes such as: Calculus, Linear Algebra, Physics, Chemistry etc.
There were two required CS courses (one in the first semester of first year and one in the second) The first semester course was "Intro to programming and algorithms" which began by assuming no one had any prior programming experience and started with the very basics "This is a variable", "This is a function" "This is a conditional statement", "This is a loop" that sort of thing. Eventually it covered algorithms like quicksort, bubblesort etc and really helped get you into the mindset of "This is how you use programming to solve a problem" For example I remember writing code to solve simultaneous equations (i.e Linear Programming), finding line of best fit through a series of discrete points things like that.
In the second semester the required class was "Intro to software engineering" I remember the course covering things like Object oriented programming - classes/inheritance public/private members and all that stuff, this was a component on unit testing. There was also an essay component to the course I can remember having to write an essay about the Ariane 5 explosion. I really didn't enjoy this course and the impression I got was not a lot of my friends did either.
I can understand the intent of making us sit through the course but in some ways I think it did more harm then good pretty much everyone came out of that class at the end loathing "object oriented" programming. At the time it was kind of a struggle to see the relevance behind the topics covered and even now with 15 years of engineering experience working in manufacturing what we learnt in that classroom is very divorced from what goes on in the real world. When I write code I am, typically speaking, not writing complex software that has multiple reusable components that talk to each other most of the code I write is trying to solve some type of problem. When I write code I'm usually thinking in terms of mathematics and problem solving rather than classes + objects and unit tests, my code tends to be a lot more in the style that was taught in the algorithms course rather than in the software engineering course I suspect quite a lot of "research code" would be similar.
The project was to define a course scheduling system. Had to be able to define which rooms had which equipment, capacity, etc. Then professors would be able to enter their needs of time and equipment, then we'd have to allocate the classes accordingly.
It was written by one or two people, for one or two people to use, once or twice.
A good practical introduction to software engineering should cover a lot of ground and most of it is going to be non technical. Learning how to program is mostly out of scope for a software engineering introduction. Assume the students have already learned some programming language and have some experience building small programs and maybe have already had some algorithm courses, etc. It doesn't really matter what language or tools they use. For the purpose of an introduction, pick something simple where the focus is mostly not going to be fighting with the tools.
The key thing to learn as a software engineer is working with multiple people and the project dynamics that are associated with that. So:
- project management and different roles in software projects, different ways of structuring teams, etc.
- overview of different process methodologies common in the industry and where they came from: scrum, kanban, watefall (don't do this), etc.
- different types of testing and their importance for continuous integration and deployment
- different strategies for estimating cost, complexity, duration, etc. and their flaws and pitfalls.
I wouldn't expect a SW engineering course to require teaching much command line usage. That's a thing for lower level courses. Same with editors.
Don't use git if it is confusing to students. Mercurial is as good and much friendlier. The potential benefits to git are fairly advanced and will not have any impact at an introductory level. Your goal is to teach the concept of revision control, not the internals of git (which every git advocate says one should know if one wants to use git well - just search any HN thread that comes up about git).
As for Python vs Python3: Again, I would not expect a SW engineering course to teach any language. The course should let the student pick a language of his/her choice.
The discipline of software engineering has not changed much for decades. To teach effective software engineering, we need to start with the principles. Some fundamental questions:
- How do we create functional and scalable software?
- Given an existing (complex) software system, how do we maintain and incrementally improve?
One important principle I learned outside of school and training: software is never just code, we always need to think about the user ecosystem around the software. Failure to understand this principle leads to wasteful effort. For example, attempt to rewrite of the code.
These principles are very abstract. We cannot teach them easily. People use tools and new technology to cover up their lack of understanding.
In college, the way my professors got around this and other things like it was by creating an alias file and scaffolding code. We would get a project that was 1/2 done with all they annoying crap, and then only have to implement the algorithms. Then we would save our work with a single simple command with no options, that was just a shell script for all the source control steps (rcs at the time, but the idea is the same).
They never actually taught us about source control. We just learned it on our own when we stopped having access to their aliases. But at that point we had enough knowledge that we could figure out it (or we were in our first job and the senior devs taught it to us).
And git (the cli not the versioning approach per se) never made sense to begin with. It is extremely user hostile. So no surprises there.
Especially if you are a beginner, this doesn't make any sense (and not even later in many cases)
In my experience during the last two decades or so in the industry, there is always a special kind of person in the IT field who takes pride knowing all the nitty-gritty details of the latest shiny versioning tool. Should it be IBM Clearcase or SVN or CVS or Git or Mercurial. Even though that most of these softwares only slightly improve the user experience and only claim to solve the users' problems, so they over promise and under deliver. But there is this special kind of person who takes pride in it.
To me this seems like someone who takes pride in knowing all the details of his toaster. Might be impressive, but also completely irrelevant for the 90% of the toaster users.
Nobody. It is a strawman or should be.
You can teach everything a beginner need to know about git as an ordinary team member in less than one A4 page and less than half a days work.
Of course this means part of what you teach then is when to talk to the git expert on the team but as long as beginners stay away from squash, rebase etc they should be fine.
Ok, add another half day about effective diffing and merging too, it is a big topic and useful outside the context of git too (local history etc).
The thing is, if you ask 10 git experts what should be taught to a beginner, you'll get 10 different A4 size pages. As an example, when my team (finally) switched to git, the expert on the team made a tutorial on what commands to use, and what to avoid/ignore. Looking at it now, he taught that rebase is almost mandatory and gives problems you're guaranteed to run into if you don't use rebase.
Not saying I agree with him, but that is one problem with git - no clear consensus on beginner friendly features.
The other thing is that the dev community has settled on a small range of simple and effective git workflows, where you only ever need 6ish commands, but check this out from man giteveryday (which man git sends you to if you want a simple answer):
satellite$ git clone mothership:frotz frotz (1)
satellite$ cd frotz
satellite$ git config --get-regexp '^(remote|branch)\.' (2)
remote.origin.url mothership:frotz
remote.origin.fetch
refs/heads/:refs/remotes/origin/
branch.master.remote origin
branch.master.merge refs/heads/master
satellite$ git config remote.origin.push \ +refs/heads/:refs/remotes/satellite/ (3)
satellite$ edit/compile/test/commit
I mean it's cool for a power user but a little intimidating for someone who just learned about man pages. Of course if you copy and paste it those (numbers) are going to give some weird errors.
Edit: I should mention that despite the critique I appreciate all the incredible work they did in exchange for absolutely nothing from me.
The terminology is just a beast. I feel like every term / command is a bit of a hieroglyph that means nothing on the surface and then I have to associate with some other thing (possibly more hieroglyphs) and memorize.
Few git... isms really tell me / give me a clue what it does.
It feels like programming in a foreign language (god bless you folks who do that!) where I just don't have anything to hang on to, just memorize it all.
The reflog is one example. Instead of copying and pasting hashes and checking out each one to see if it had the changes you want, just click the Recyclable Commits box and every commit from the reflog shows up in the normal commit and branch display. Just click one to see its changes, or click two commits to see what is different between them.
I think the biggest problem for people new to git is that it solves problems they don't really have yet. They are solo on their own repo.... they don't see the point of branches, they only really ever need to stage/commit/push all their changes to a remote. So they learn the magic command line incantations until the day it goes wrong somehow, or they need to roll back, or need to start collaborating and they have to dig a bit deeper
"Let me try....oh gawd this turned into a mess!"
You can always go back and add a branch onto any commit. Just right click the commit, select "add branch", and give it a name. You can move branches around by dragging them and immediately see what branches are where.
And if you really mess up, click Recyclable Commits, and any commit you thought you lost will be there.
Do they have a free personal version?
> A purpose is considered non-commercial only if the SOFTWARE is exclusively used to actively work on open-source projects, for learning or teaching on a public academic institution, in the spare time to manage projects where you don't get financial compensation for (hobby usage), by public charitable organizations primarily targeting philanthropy, health research, education or social well-being.
Git takes more and people constantly ask questions or have to have cheat sheets printed.
The other thing is that students are also scared to get their hands dirty with git. Some of them don't fully understand source control and therefore they are terrified that if they commit/merge something incorrectly then they will destroy the whole code base.
Working with a "throwaway" local repo was crucial when I was learning git. It was just a handful of gibberish text files in a few directories, and I experimented with "what happens when I run this git command?", comparing what actually happened with my expectations of what would happen.
That explains rebases...you take one branch and put it on top of another branches commits but REWRITE those new commit id's based on the new branches commits.
Merges, you keep the same commit ids but smush two branches together.
Also, when I do a git reset HEAD~1 and make changes I can force push and understand the my new code is overwriting the last commit.
I think that really helped my understanding of git.
Why do people persist in pushing one of the most user unfriendly tools to ever exist?
Another reason it's difficult to teach is because of a complete lack of a legitimate discipline to teach.
a) Everything is the "tip of the iceberg" - which makes teaching what you actually want to teach tricky. Which is why so many resources do the whole "we won't go into it, because this is a large topic." For example, Linux. Most projects and resources require this, but barely any actually go in-depth.
b) Everything is always changing - and so you have to either support your students in the face of these changes or constantly keep the materials up-to-date. This is one of the largest challenges, if not the largest challenge.
c) Everything has to be engaging - it's not enough to know what you're talking about. You have to know how to talk about it in a way that creates engagement and thus learning. This isn't something you learn how to do when slinging code left and right.
d) Everything needs to be TAUGHT, not said - the ability to teach is often an after thought for folks looking to educate. If you want to really help your students, you have to learn how to teach so that they can think independently. Not rely on cheatsheets, prep tests, and step-by-steps.
e) Every student needs the motivation to learn - usually instructors' will stop at spitting out their knowledge. The best instructors help their students push through their barriers, whether personal or professional, and get the learning done. It's easy to learn in a structured school system. It's hard to learn when you have multiple kids, a full time job, and all the emotional baggage of being an adult.
Now, to be clear, I'm talking about teaching modern, practical implementations of software...not CS theory or other things that are far more evergreen and less technical.
One thing I learned while teaching complete novices is that it is really hard for experienced engineers to get into the mindset of students. You need to forget everything you know and start more basic that you think it's necessary. You will need to teach people what are variables, list, functions, and so on.
As an example an student got confused when we wrote something like the following:
let X = 1; let X = X + 1;
How could X be X + 1 at the same time? Maths don't work that way!. It might seem absurd to a programmer, but if you are in the mindset of someone who is only familiar with maths equations, it makes sense.
So yeah, I would forget git, command line, tangents and whatnot, and focus on very basic concepts instead.
So to become a "real software engineer" and not "just a programmer" one needs to know how to create requirements, use source control, do modular, and/or object-oriented and/or functional design, deploy your software, and take advantage of open source?
Those are things that all programmers need to know (assuming "programmer" means someone whose primary job is programming). Which is why the distinction between "programmer" or "developer" and "software engineer" is bogus. Its usually just an attempt to justify higher or lower compensation.
I think the harder thing is training sysadmins, there’s no real formal education. I know we’re downplaying a lot of the traditional sysadmin roles and pushing for more development in sysadmin but the sysadmin approach is still required, and the only thing that keeps it going is the corpus of industry knowledge, a myriad of vocational or vendor based certs and a willingness to teach.
Or am I wrong?
It could catch common errors and provide useful explanations. It could possibly even go as far as attempting to understand plain text commands, eg "delete the file file.txt" and suggest commands to do that.
Or just contextual help as it existed in many Windows applications (and certain current iOS apps).
https://www.youtube.com/watch?v=I9LZ6TnSP40
https://alumni.media.mit.edu/~mt/thesis/mt-thesis-Contents.h...
https://www.youtube.com/watch?v=QTJRwKOFddc
https://github.com/pharo-open-documentation/awesome-pharo-ml
(And no, there is nothing special about copy-pasting commands and Unix pipelines that cannot be easily recreated in UI if the UI is designed to be programmable. )
Jokes aside, Jupyter and relevant projects are great tools but they drive programmers towards wrong paths.
You'll pry vim from my cold dead fingers.