> But look at this guitar player with blisters. A harpist has blisters, a base player with blisters. There's this barrier to overcome for every musician. Imagine if you downloaded something from GitHub and it gave you blisters. Right? The horrors!
That whole talk is filled with some interesting takes on designing and building software (with the usual skew that paints Clojure in a good light, so take it with a grain of salt if necessary).
[1] https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
I'll have to remember that next time someone mentions that C should be a dead language.
(I actually think C is a fine language, but should be deftly handled)
You mean Haskell?
There are two issues here:
a) Designers trying to simplify everything beyond usefulness is a good instinct gone haywire. Simplification helps, but without an understanding of accidental complexity versus essential complexity, one is bound to end up painted into a corner with no flexibility left in the app. Few designers understand this, and those who do got it the long way round — by working on products that have a lot of essential complexity, like AdWords, and by repeatedly fighting those battles
b) An engineer's operating environment, OS, IDE, shell, terminal, is a reflection of the inside of his or her mind writ large. Like every Jedi has to build their own lightsaber, every engineer has to go through this pain of building out their weapon, because one's workflow is how one thinks, how you look at the problems at hand. No UI designer can help with that.
[0] (Because it's relevant to the context: ex-Google, ex-Facebook as professional experience)
There is a great little book - Daily Rituals [0] - that goes into many artists' and scientists' daily habits. The habits are very much along the same lines as your thought - they are workflows for how the individual tends to think best.
I'd love to see someone put together a website or book that did that in the context of software engineers' workflows. Does someone know if a resource like that already exists?
[0] https://www.goodreads.com/book/show/15799151-daily-rituals
-edited for grammar.
How did you juggle acquiring skills for both roles? Also, where there times you had to struggle between the two mindsets on a task?
I get your complaint; my father is a fully qualified and slightly/weirdly eminent electronics engineer (and IEEE member), so from a young age I've been made aware of the sanctity of the term in that context.
But the term has been used in other contexts for a long time, and most people understand the distinction.
It's not a hill worth dying on. Best save your energy for more important battles.
Furthermore, tons of experienced working engineers outside of software don't have PEs. They're just not needed in a lot of contexts.
Edit: I'm referring mostly to the US. Licensing bodies in some places (perhaps including some US states) may say that only licensed engineers can be called/are engineers although the degree to which such strictures are followed will almost certainly vary. (I was told this was the case in Texas but there's no shortage of people in Texas who call themselves engineers but aren't PEs.)
Why should they get to do that? What do they know that I don’t?
I have a Master of Engineering degree but I’m not chartered - I’m still going to call myself an engineer no matter what anyone else thinks about it.
> You don't call yourself admiral right?
Because I’m not commanding a fleet. If I ever came to command a fleet I’d start calling myself admiral and as long as I’m actually doing that it’d be fine. If you’re doing engineering then you’re an engineer. Some of the best software engineers in the world have no professional qualification.
However, if I were to start practicing medicine in anything other than a first aid context or if I were to mislead people into thinking I was a certified medical professional, that's not allowed legally.
By contrast, while PEs are required especially for signing off on certain documents in civil engineering, there is not in general any requirement to have one to practice engineering in the general case. In fact, there's no requirement for an undergraduate degree.
> just anybody can call themselves engineer?
> It's not about titles.
It was about titles!
What you cant do is profess capital ‘E’ engineering work without running afoul of the law. That’s akin to practicing medicine without aboard certification, even if you claim to be a doctor because that’s what your degree says.
Degrees and licensed are related, but different in terms of the profession.
I honestly think that software "engineers" should be legally liable for the lives at stake though.
I'm not an accredited engineer, so I feel I have no right to the title.
It really annoys me that some manages at work call themselves Release Train Engineers.
Generally I think an engineer as someone that does design. Key part of that is some sort of analysis. That can be ad hoc, standards based, or formal.
Most of the time software feels like craft to me not engineering. Otherwise I'm more on the side that a license an engineer doesn't make. There are engineers without degrees designing and there are fat fuck PE's that just sign their name over and over for $300/hr.
[1] https://www.nspe.org/resources/pe-magazine/may-2018/ncees-en...
Added: So, basically the grandparent registered on HN so they could leave comments about how people without PEs shouldn't be allowed to call themselves engineers.
Shout out to the people that don't really bother because they're good enough to adapt to any setup. :)
Many mice are ambidextrous (e.g. the Apple puck). Most are weakly right-handed with a slightly assymetrical shape. Some are very strongly right-handed (e.g. vertical mice) and can't be used sensibly in the left hand. So left-handed mice also exist.
Some people are naturally left-handed. We (as a civilisation) used to treat this as aberrant but have now recognised it, and that different tools suit different people.
I believe that something similar exists in programming tooling in relation to how people think about programs. There are clearly some people who have a strong, unusual "handedness" and have developed tools to match (e.g. Colorforth). A few people discover these and find them amazingly usable. Most other people find them baffling.
Consider the three propositions:
a) Jimi Hendrix played guitar in the wrong way with the strings in the wrong positions
b) Jimi's configuration was correct and everyone else was wrong, because he's producing the objectively best music
c) Jimi was left handed, and had constructed an accomodation which worked for him but should not be expected to work for anyone else
Far too many discussions of programming tools devolve into (a) versus (b), largely because people want there to be an objective ranking of who the best programmer is and what the best tools are, rather than allowing for diversity of (programmer x tool).
Pretty sinister, if you ask me.
And I feel this is a very similar situation with other tools. I edit code with vim, in a terminal. This is simple as dirt. I do it because it is simple as dirt. Visual Studio is incredibly complicated to me because to do the creating code part my job I need to understand the following:
- How code is built.
- How to build the code without using any graphical front end.
- But now when you bring VS into the mix I need to also understand visual studio. It does not remove complexity, it adds it.
Similar thing with debugging, I need to understand all the ins and outs of debugging but now bring VS into the mix and I need to understand it's stupid UI.
I like simple, my mind is simple. I can learn things, if there are rules and patterns it makes it easier to learn, but the less things I have to learn the happier I am. I don't have an option to not learn some things, like how to do build automation, how to debug code, how computers work, etc. But I do have an option to not learn something entirely useless like VS.
I think the lie being sold is that somehow you can be a programmer without actually knowing how to use a computer. And to know how to use a computer is not the same thing as knowing how to click on things in the UI with a mouse. To know how to use a computer you need to understand how to use it to do automation - and once you need to do this VS is just a nuisance.
Just a rant I guess.
Sure, the pickaxe is simpler, but it will take you a lot longer to break that concrete with a pickaxe than with a jackhammer, because of simple human limitations.
Similarly, refactoring and advanced code navigation support takes a while to learn how to use, but once you do, it empowers you through technology to quickly do things that your mind would take much longer to do by hand.
For example, say you want to extract some code from the middle of a function into a separate function. With vim, you would generally have to manually move the code, write the new function header, then start to painstakingly inspect the code to identify the parameters to pass between the two. You will probably make mistakes and have to wait for the compiler to find them. All in all, assuming it's a bit of hairy code, it might easily take you more than an hour to get it working. In VS, you would type ctrl-r, ctrl-m (Refractor, extract Method) and it would automatically detect all of these for you, pop out a dialog box, you'd enter the new function name, Tab, param name, tab, param name etc, and enter when you're done. Maybe 5 minutes all in all, assuming you also do some ctrl-r, ctrl-p (refractor, parameter) afterwards to extract some larger expressions back into the original function.
Similarly, you have things like 'analyze data flow to...' which can find all places in your program where a particular value can be written to, and do that recursively until you get to the original source. Same thing - this can be done by hand with a series of finds and so on, but an advanced tool will just help you do it faster.
But, just like with advanced editing in vim, you need to take the time to learn the tool until you can get the most out of it. Same as the first time you enter vim you're likely to fumble to even be able to exit, you can't expect to be productive in VS if you don't take the time to learn what it can do for you.
Wait, what happened to XFCE? I use it right now.
I'd look into switching to Fedora. I use the XFCE spin and it is stable.
Your tools, then again, chainsaw, microscope, text editor... have no reason whatsoever to have an UI that is intuitive without training[1]. Because without training you are anyway going to be either dangerous, useless or in best case just really unproductive.
[1] of course, the UI needs to be efficient after training.
For professional tools knowledge encoded in the head supported by appropriately encoded knowledge in the world absolutely is a viable approach, provided there's appropriate feedback and conceptual mapping corresponds to the mental model a user has about how that tool works, i.e. actions and reactions should be consistent.
With modal design patterns such as the ones used by vi, for example, this can become a problem.
And this isn't just me saying that because I like vim. It's because of the objective fact that nearly every developer tool that is created will include a vim mode. And if included as an extension it will often be one of the most popular extensions. What that objectively indicates is that there is a large contingent of developers who genuinely find the vim modal editing UX excellent, to the point they seek it in other tools as well (including browsers, mail clients, RSS readers, etc).
What I would say is that vi really doesn't give you a lot of interactive context -- and it's hard to add it on.
It's simply not possible to learn vi by just using vi.
Also, the author emphasizes that just dumbening a product is not the solution.
A quick summary of my experience:
- Most complex apps are not learnable linearly: Ableton Live, Final Cut Pro, Logic Pro X, Photoshop, After Effects, Blender, all practically require reading the manual.
- A few apps are ok at it: Adobe Lightroom, and Sketch, although those apps also are probably less powerful than those in the first category, e.g., Photoshop can do the majority of what both of those apps can do, and more.
I would actually put shells and text editors as some of the easiest complex apps to learn linearly, because you can do so much with them with just cut and pasting text from the internet. Try following along with a Blender tutorial video that's not for an absolute beginner, and you'll get stuck almost immediately, because you won't know the keyboard shortcuts to perform the actions in the video. This happens far less with programming tutorials involving text editors and terminals.
I did. I learnt vi when I was told go fix this file on that computer, you have ssh, x forwarding won't work because you have 3 hops (embedded devices that won't allow forwarding of any kind), there is only vi on the box.
So I figured out how to use vi. It is not rocket science, there is not that much to learn, vi muscle memory takes time but also not even that long I think.
On the other hand: I don't see what's so bad about a product for professionals where you might need a teacher to help you learn. Photoshop is not a simple product to use if you've never interacted with it before and most users go through some tutorial or has a teacher or something. It doesn't mean that Photoshop has bad UX. This goes for lots of software made for professional use: try learning Autodesk Maya or Avid without external resources, I dare you.
Emacs is the same.
As positive examples I would point out the kind of interactive editing mode that you can find in dependently typed programming languages. I believe e.g. Idris has a pretty cool Emacs mode.
This stuck out to me, there seems to be a trend in UX/UI where any move away from the "simplest path" is seen as a huge negative. Could it be the case that we use these tools (especially UI patterns like vi) because after the learning curve the give a huge amount of value? It seems like we are assuming that we should make a developer tool with the same level of "immediate familliarity" that we try to build into a website where customers will bounce easily, for an audience who is willing to spend time learning a tool if it provides value to them.