Coming from Alan Kay i definitely need to check these out. If I'd read this post a year ago I would have known almost none of the authors, but after reading "Hackers: the heroes of the computer revolution" earlier, these are all names that stood out right away.
Both Minsky and McCarthy seem like almost mythical figures in the book, and I don't think I could ever hold aa candle to them, but the next best thing is probably to understand their thinking. I think it's a bit easy for us to get caught up in the medium blog posts detailing a small segment of a new framework, when what we really ought to do to grow, is go back to the basics and understand them in-depth.
Another great book by Minsky is Perceptrons. It's really short to boot, IIRC. It is an especially good book for those interested in ML. In it Minsky shows that single layer neural nets can not compute all problems. I remember that he has a caveat somewhere that he hasn't thought about multi-layer neural nets and they they may still be interesting. So great was the impact of this that hardly anyone worked on neural nets for something like a decade afterwards. But it's a brilliant book presented in a really simple style. It's a piece of history, I think.
Abstract: Freud's theory of jokes explains how they overcome the
mental "censors" that make it hard for us to think "forbidden"
thoughts. But his theory did not work so well for humorous nonsense
as for other comical subjects. In this essay I argue that the
different forms of humor can be seen as much more similar, once we
recognize the importance of knowledge about knowledge and,
particularly, aspects of thinking concerned with recognizing and
suppressing bugs -- ineffective or destructive thought processes.
When seen in this light, much humor that at first seems pointless, or
mysterious, becomes more understandable.
A gentleman entered a pastry-cook's shop and ordered a
cake; but he soon brought it back and asked for a glass of
liqueur instead. He drank it and began to leave without
having paid. The proprietor detained him. "You've not
paid for the liqueur." "But I gave you the cake in exchange
for it." "You didn't pay for that either." "But I hadn't
eaten it".
--- from Freud (1905).
"Yields truth when appended to its own quotation"
yields truth when appended to its own quotation.
--W. V. Quine
A man at the dinner table dipped his hands in the
mayonnaise and then ran them through his hair. When his
neighbor looked astonished, the man apologized: "I'm so
sorry. I thought it was spinach."
[Note 11] Spinach. A reader mentioned that she heard this joke
about brocolli, not mayonnaise. This is funnier, because it
transfers a plausible mistake into an implausible context. In Freud's
version the mistake is already too silly: one could mistake
spinach for broccoli, but not for mayonnaise. I suspect that Freud
transposed the wrong absurdity when he determined to tell it
himself later on. Indeed, he (p.139) seems particularly annoyed at
this joke -- and well he might be if, indeed, he himself damaged it by
spoiling the elegance of the frame-shift. I would not mention this
were it not for the established tradition of advancing psychiatry by
analyzing Freud's own writings.
I read it fairly recently, and I agree that it is both great and short.
Regarding multi-layer neural nets Minsky says they're uninteresting as they could be declared with enough complexity to basically reimplement any existing logic circuit. What made multi-layer neural nets interesting again was a multi-layer training algorithm.
There another interesting part, shortly after showing that single-layer neural nets can't implement the XOR function, Minsky shows that all that's required for a single-layer neural net to implement the XOR function is to add another column to the training set with specific values, effectively encoding the hidden layer back into the training set.
The Levy "Hackers" book is what told me there were concentrations of other kids who liked to figure out and build things as much as I did.
I eventually found my way to Minsky's class. It was nominally on one of his past books, but the class sessions often seemed to be him talking about whatever he was thinking about that day, as he worked on his next book.
Minsky's "ten-year grad students" and unofficials were also great. Two of them were especially personable, and would wander around the lab, and strike up impromptu technical conversations with random other enthusiastic students. Which seemed unusual among grad students of my dotcom era, and maybe it was more old-school greatness, like the Levy book.
There's also a bunch of stuff at oldlinux.org though (obviously) all Linux-related. "A Heavily Commented Linux Kernel Source Code" is also available in English now (scroll down to the top of the change log).
I love that Joe Armstrong's PhD thesis is on this list. I have it on my reading list for junior engineers. It's incredibly accessible and the mental model is very powerful.
Yeah, how accessible is a 295 page PhD thesis where half of it is Erlang specific for junior engineers? Unless you want them to quit their jobs, or complain to their friends what a crap manager they have.
Relax. Nobody said it was a mandatory reading list. There are no tests. It's a suggested reading list that I pull from depending on context. Joe's thesis is incredibly accessible.
At least two of my items were on Alan Kay's list. The other being "The Mythical Man Month", especially the edition with the "No Silver Bullet" article, which a depressing number of people in our industry seem to not have read. So I don't feel like I'm too far off the mark.
I have read "Lisp 1.5 Programmers Manual”, “The Mythical Man-Month” and “The Meta-Object Protocol” by Kiczales. These all are definitely timeless classics.
"In Lisp, if you want to do aspect-oriented programming, you just do a
bunch of macros and you're there. In Java, you have to get Gregor
Kiczales to go out and start a new company, taking months and years
and try to get that to work. Lisp still has the advantage there, it's
just a question of people wanting that." -- Peter Norvig
"I am reminded of Gregor Kiczales at ILC 2003 displaying some AspectJ to a silent crowd, pausing, then plaintively adding, "When I show that to Java programmers they stand up and cheer." -- Kenny Tilton
Agreed, and I also think "annotation oriented programming" has become the bane of Java programmers everywhere.
Seems simple when you first slap an annotation onto a class or method. But God help you when it stops working and you actually have to debug what it's doing. Figuring out what code is actually executing and what it's doing seems nigh impossible.
(Which is all to say, Lisp is still far superior, because there is a straightforward process for figuring out what kind of code a macro will generate, or to run a macro and look at its output. Macros can become complex and convoluted, but that's still nothing to the mess that annotations in modern Java frameworks create.)
You can debug an aspect too eh? Throw a breakpoint before a method call, step into it, "oh I'm in a proxy now" step step "oh I'm in this forgotten point cut I made 6 months ago, okay now I know."
I have no exp with Lisp so not arguing just observing the one side of exp I have.
Does anyone else get scared that too much breadth will stifle them? CS is a massive field these days and you could easily sink all your time into a small area without fully mastering it. I have had coworkers before and who could speak at length about different Linux distros, networking, web dev, dbs etc. but then were not great at the meat and potatos of the job.
It's a legitimate concern. I spent 4 months of evenings and weekends(could have been one or two to be honest) to prep for the Google Cloud Architect exam. I have used NONE of this knowledge (past what I already knew - load balancing and spinning up VMs/containers...I think I used Dataprep instead of a Excel once too for shits and giggles).
I am looking to spend another 4 months learning ML, which I likely won't apply in any way.
That's a year down the drain with ONE cloud provider and ONE way of doing ML. It's easy to completely waste your life like this WITHOUT getting better at your job.
Carry-over is far more limited than people make it out to be, unless you REALLY know a lot, but those people are rare.
Being 35 and having worked in IT for 15 years now and seeing the rapid acceleration into DevOps/Cloud/nix/Programming/Stacks I fear for my future. I want to learn a ton of stuff, but the vast amount of stuff needed to learn in order for me to move up in my salary bracket is stifling. AWS/Azure/+ the former I mentioned, then Python, YAML, Cloud networking. I'm good at some stuff, but the industry is just moving so ultra fast now it's hard to keep up.
I've been contemplating getting out of IT altogether because I'm not fully confident in career growth at this point unless I murder myself with study and ignore my family.
I've been a MS SysAdmin for 15 years, moving into nix devops (the new way of sysadminning) isn't easy.
You seem to need to study programming before being able to do real DevOps. nix is kinda advanced in this sense even if it is has a small language. In my experience, very few ops are able coders.
Interestingly, earlier in my career, most of the developers I worked with were also capable at system administration, and could easily fill that role if needed.
The sysadmins during that time were quite capable, but had no desire, or an admitted lack of ability for a development role.
Given their background I think they meant nix as Linux/Unix and not Nix the programming language/package manager.
Despite its clear fit with the current hotness of immutable systems and functional programming, I don't think I've seen anyone in for-profit industry on a Nix/NixOps stack.
"unless I murder myself with study and ignore my family"
I think this is completely true as well. To move past senior developer, you fall into one of these camps:
1. Very bright.
2. Spent a LOT of time studying or messing around with the right tech on your own.
3. Sell your soul, i.e. ignore (or not have) family/kids.
A lot of people from camp #1/2 don't understand that for most, #3 is the only option (in the short term). There is also the very real tradeoff of not going with #3 and risking declining job prospects/salary.
I think this is doubly painful for devs, because they are generally used to quick career progression / salary bumps, and then it stalls hard at senior dev.
Why do you need to progress past senior developer? Senior developer jobs provide interesting, fulfilling work, and excellent salaries (probably 90th percentile).
Um, I know lots of 50 year-old (and older) senior developers.
I'm not ignoring the fact that ageism is a real thing (it most definitely is), and it is more difficult for many older programmers to "keep up", but that doesn't mean that no one is doing it.
I'm a little confused, because I wasn't aware that there was career progression beyond Senior Developer. I mean, you can go and lead a team or something if you want I guess (in fact, I'm doing that at the moment), but most older developers I know have been and done that, and settled back in highly-paid, highly-respected, and much easier individual contributor / architectural roles. Looks like a good life to me!
The best developer I've ever had the pleasure to work with was a 50-year old senior developer. He cut his teeth doing a lot of C/C++ stuff back in the day, but was also (pretty successfully) leading the company's adoption of Angular. If you have a sharp mind, and you don't get stuck in your ways, then people will be begging for you to be their 50-year old senior developer.
I know more than a few places that have Principal Developer positions. This is basically for senior devs who have tons of domain knowledge that companies don't want to lose.
There is strong cultural pressure (at least in the US) to constantly progress in your career. This is measured primarily by title and compensation.
I've been a senior developer at the same company for 13 years. I feel that most of the time, I am progressing in my knowledge and experience, so, in my mind, I am making progress. It just doesn't seem that way on my Linked In profile.
What prevents title changes if only to please the LinkedIn profile? Junior - Senior is a change that occurs within the first 5-10 years. Isn't there a way to discuss with your manager for title changes just to show you haven't been doing the same thing?
Deputy Developer? Elder Developer? Doyen of Development? Development nestor of company X? Director of Engineering at Sub-sub-sub-sub-department that happens to be just your team? Level 20 Wizard? Does it even matter if it sounds good on LinkedIn?
Our engineering job ladder does not recognize any differences in core software engineering skills after Senior. It is entirely about social and organizational skills.
Running contentious meetings and herding directors are difficult skills to even begin to practice on your own time, but navigating family life is probably as close as you can get.
Maybe this is a good place to articulate what's been on my mind lately regarding growth. I don't think there's much local opportunity for developers beyond starting their own businesses past the senior level. Instead you have to be willing to move. Individual companies will not be able to challenge you beyond their business needs.
The other thing I wanted to talk about is how I solve technical problems. The first thing I do is get a representation of what the problem is in my mind enough to where I can see a clear path forward. This leans on my ability to take a 10,000 foot survey of a problem space. My current role deals with microservice architecture. Microservices is right in my wheelhouse due to my better-than-average sysadmin skills.
But I end up having to learn a lot within a short amount of time. So in order to cut down on what I call the "sheer mass of information needed for mastery" any time I look at a new tool or tech, I make a beeline for the "architecture" or "concepts" page. This is where I work out exactly which concepts and which level of the architecture I'm working at.
I then use the problem statement and vision above to hone in on a perfect implementation. Then I look at the actual state of the system and work to bring it more in line with the perfect one.
I recently was tasked with getting one of our guys unstuck. He was having a tricky issue with aquasec that he'd been beating his head against for a week. It took me five minutes to understand the problem, then I went to my desk and spent twenty on obtaining a reproduction. I didn't want to redo his work, so I then asked him what happened when he did X and Y. From his answers I had a clear path to being able to demonstrate that it was aquasec throwing a false positive on a npm library, and was already in talks with our devops team about next steps. It took 30 minutes for me to move his issue forward.
I feel like this manner of solving issues with techs that you don't necessarily have full understanding of could revolutionize the industry. But I can't really grasp how to teach it. It looks like magic to people when I show it to them, they think it relies on years and years of experience. I mean, it kind of does, but I was able to avoid ever getting fully stuck on problems even as a teenager.
But stretching out the problem space and treating each barrier in turn, diving in a little bit into complex techs along the way, I don't see a lot of coders doing that. Instead they just kind of muddle around with what they know, believing they need perfect understanding of a tech before being able to solve problems effectively with it seems to be the norm. And we have this tech landscape where years of experience in technologies becomes the primary determinant behind how most employers judge candidates.
I think the increasing march of devops and other techs that purport to unite the whole world into one walled, splendid garden will eventually bifurcate the tech world into supermen who know everything, and the underclass who can only work in one garden. If that's not how things already are?
Maybe a secondary school for advanced coding or bringing guilds back.
I feel a similar way, and I'm a little bit older with a fairly strong desktop/web/mobile dev background. My focus was heavy on Microsoft technology before moving 50/50 to Linux.
I look at industry as a series of different waves happening where I just need to get on one so that I can find the next. A wave is going to cross the startup world before it moves into established business. If I time it right then I can hang in there for a while. It doesn't help with my anxiety, but I've done this before so I know I can do it again. I suspect I'd find the same pattern in a closer examination of your background.
There are very few people learning all of these technologies because time is required to learn the basics, as well as put it into practice within industry. That's deep learning. A lot of people are lucky to work in places that will put unproven technology into production. The number of places willing to take this risk is increasing because cool technology is a requirement for attracting top talent. If you are in a more risk-averse organization it may seem scary to move to a faster moving, less risk-averse one, but you might find they actually have more leeway for mistakes and learning.
I watch for particular patterns around how a technology is hyped and who is applying the technology. Thoughtworks publish their perspective (https://www.thoughtworks.com/radar) and I try to read this, plus other analyses to understand what direction things are moving in. You have to take a longitudinal view. It's not good enough to just compile your research and make a decision. You need to know how a technology has moved over time. Once you start doing this you start to develop some "spidey" senses when you see something at the top of HN - and you don't have a ramp-up cost each time you have to make a switch.
Other than that focus on a few fundamentals, including one programming language reasonably well. I'd strongly suggest learning Python and having an incremental two year development plan so you don't half-ass it. A lot of the Linux world is built on stable skills. Rather than focusing on AWS, or Azure networking learning networking and TCP/IP beyond a cursory level. There are a lot of folks building cloud infrastructure badly, slowly etc. because they don't understand these fundamentals. The references are old and boring like TCP/IP Illustrated Vol. 1.
'I've been contemplating getting out of IT altogether because I'm not fully confident in career growth at this point unless I murder myself with study and ignore my family."
That's a real problem. I had a few years when I worked on pretty cutting edge stuff so most of my learning was on the job and could be applied quickly. In my current job there is a lot of repetition and stagnation so you have to spend a lot of time outside the job learning stuff which you then never apply. This gets really old after a while.
As an MCSE from the late 90s, I can tell you with oldfart-confidence that you can rely on Microsoft maintaining a landscape where you can be an MS-only sysadmin for decades to come. Sure, the salaries might not be stratospheric, but corporate AD & GPO work will be never-ending. There are lots of businesses running on Windows laptops and desktops and that ain't changing.
yeah, I would agree with this. You may not have the servers locally, but there is still a lot of admin stuff to do, and Azure doesn't configure itself.
I would suggest attempting to learn the general principles behind the one way to do ML/cloud/whatever you have studied. That type of breadth of knowledge is the useful one. It lets you gain further knowledge much more efficiently. As I mentioned above, to great extent breadth of knowledge is about learning how to be an efficient learner.
I would say the most important knowledge is the one that allows you to ask the questions of "why is it still not done?" or stating "well, they did it, but it won't work well in situation X" and then either finding the products that do exactly that, or knowing that in a few years there will be an industry providing exactly that kind of service.
Saying that you can't move between cloud providers because you need to learn something new probably implies you don't understand the fundamentals constraining the design of e.g. databases provided by cloud.
Reconcile that value of experience... with commonplace startup hiring age biases, and dotcom interview processes biased towards someone with CS101 fresh in mind and who perhaps just spent months practicing leetcode whiteboarding. :)
I disagree with the premise itself. Breadth of knowledge is not obtained because you will use every single piece of it, rather because you will be able to make connections between disparate topics. When you have breadth of knowledge you know which reference to pick up for help with your new exciting problem. (I am assuming it is a given that breadth of knowledge does not imply only superficial knowledge).
Lastly, having breadth of knowledge means you have learned how to learn efficiently. This is a significant force multiplayer.
I would even go so far as to disagree with one of your sibling comments in saying that this reading list is important because it isn’t about “arcana”. Arcana is what usually gets you the last 10%* of the way to a working solution, even if your high level approach is beautiful and pure.
An old-style hacker reads man pages, RFCs, specs, and programming books not to immediately know how to solve problems at hand, but to know what solutions are possible for future problems. It isn’t useful to know that the HTTP spec doesn’t specify a max header length or that the default setting on Apache is to only accept 8kb of headers, until it is suddenly extremely useful to know both things at once :)
Good luck with that, especially, but not only, with git man pages.
I tend to avoid reading these “just to know” but only when I need something specific. They are mostly torture. They could have been more useful to read but they presently aren’t.
The git man pages is famously inaccessible if you don't already know the concepts and jargon of git. The following auto generated satire is both hilarious and sad if you have read the actual git man pages:
To compare, a real small part from "man git checkout":
"git checkout --detach [<branch>]
git checkout [--detach] <commit>
Prepare to work on top of <commit>, by detaching HEAD at it (see "DETACHED HEAD" section), and updating the index and the files in the working tree. Local modifications to the files in the working tree are kept, so that the resulting working tree will be the state recorded in the commit plus the local modifications.
When the <commit> argument is a branch name, the --detach option can be used to detach HEAD at the tip of the branch (git checkout <branch> would check out that branch without detaching HEAD).
Omitting <branch> detaches HEAD at the tip of the current branch.
git checkout [<tree-ish>] [--] <pathspec>…
Overwrite paths in the working tree by replacing with the contents in the index or in the <tree-ish> (most often a commit). When a <tree-ish> is given, the paths that match the <pathspec> are updated both in the index and in the working tree.
The index may contain unmerged entries because of a previous failed merge. By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. Using -f will ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by using --ours or --theirs. With -m, changes made to the working tree file can be discarded to re-create the original conflicted merge result."
It has been widely confirmed that going for a wide breadth only makes you good at architectural type jobs where you orchestrate multiple separate silos of knowledge coming together, without actually knowing the details too deeply but instead simply trusting that they will interface correctly.
If you try to have a wide breadth and a deep knowledge simultaneously, you will pay a heavy price. You will not have much of a family, you will not have other hobbies, you will not know much beyond CS, you will not even have time to use the vast majority of your knowledge to its full depth. There simply isn’t enough time. You will likely die as you lived, at a keyboard with your head weighing down on keys spamming them infinitely in a code editor, or slumped in a chair or bed with a technical book resting on your chest. Very few people will notice your passing, and the world will be no different for whatever knowledge you gained.
What we should strive for instead is “Just-in-time knowledge”, where the goal is to quickly become an expert on a topic you know nothing about right when you need to be. Many people first learn to do this when they get into debates on the internet, and then extend it into their professional careers.
I would agree that work-life or study-life balance is important, but your comment is way over the top. One can definitely "have it all, just not at the same time"^1. "All" it requires is spending time and tought on each piece and having a support group for when you feel you are too tired.
1: Admittedly, the lottery of birth can make that more difficult.
IT is a fast-moving field. Solving business problems takes understanding which good ways to do that are currently available, what limitations and dangers each approach brings, how would it interact with other things, etc.
You still need deep knowledge, but the most efficient knowledge is that of key principles, general approaches and ideas. A specific technology does not matter much, and can be mastered quickly enough, if you already are acquainted with the principles behind it. E.g. learn about FRP, and you will see how React, Elm, and Excel all work along the same lines.
What you end up with after some time is like a normal distribution: deeper knowledge around some area and various levels of acquaintance with a wide range of other things.
There are still areas where you can polish the mastery of one narrow thing to utter perfection: making pizza or coffee, sports like running or weightlifting, etc. You can keep practicing them to counterweight the feeling from the view of the sheer and constantly moving IT landscape.
It is very waterfall-y as someone I know said in a talk and therefore you probably need to be a little careful what "rules" you take away from it. That said, the "mythical man month" discussion itself as well as the idea of a 9x difference in effort between a program and a programming system product are worth the price of admission.
The latter arguably runs somewhat counter to a lot of MVP, etc. approaches but recognizing the difference is still useful.
If you run your sprints right then no, nothing's set in stone. If something comes up in the middle of the sprint that takes priority, you address it. You don't mindlessly stick to the schedule set (that would be a "tiny waterfall.")
Fair enough. Although waterfalls usually weren't really set in stone either in my experience. Which had both good and bad points. (It's good to be adaptable but changing requirements all the time is also a good way to make a project late.)
This sounds is/ought-y? What is the prevalence of running sprints right in the real world? "As practiced" was the important part of my question/observation.
You just put into words what’s been bothering me about the way my team works. The “process” people—while well-intentioned—seem to think that by breaking inherently complex tasks up in just the right way, they can make the complexity go away.
Well, no. If that’s really the idea, why are you paying me so much?
> There are still areas where you can polish the mastery of one narrow thing to utter perfection: making pizza or coffee, sports like running or weightlifting, etc. You can keep practicing them to counterweight the feeling from the view of the sheer and constantly moving IT landscape.
Hear Hear!
When talking to Junior Devs i always point out that they should take into account the Lindy Effect and invest some of their learning time into things that were here for atleast a century so they can get enjoyment out of their accomplishment for the rest of their lives.
You don't want to die without making at least ONE perfect pizza.
Here's my approach. Do your best to aware of as many tools/techniques as possible, know where to look for information on the ones that look/become promising or useful, and build deep knowledge on the ones you wind up regularly using.
It's very useful to have enough exposure to things to be able to tell generally what's going on and to know what you need to look up.
Here is the interesting thing about reading books, I once thought reading books and remembering everything about the text is the goal; However over time I’ve learned there is value in having read the book, understanding the material and then you know where to reference the information should you need it in the future.
The books recommended by Kay here are very much about DEPTH, not BREADTH.
The majority of programming books are just ephemera and arcana and details that will be irrelevant in a year, or next month when the new version of the framework comes out.
Kay points to books, like the original Lisp Programming Manual, that will help you understand deep core concepts about computing itself, that will remain applicable no matter what framework or library you need to use tomorrow.
Take an Alan Kay, a McCarthy, Norvig, Abelson, Sussman, Armstrong, Steele, etc. from their prime and drop them into a software company where they have zero familiarity with the programming languages or tools currently being used, and within days or weeks they will be the most productive developer at that company by far. They will come up with simple, elegant, high performance and correct solutions to problems none of the other developers would have even considered.
Those are the kinds of thinkers you want to emulate, if you really want to write excellent software solving real problems in the shortest amount of time.
That sounds like JS developer mentality where you rewrite everything in a different framework every year so figuring stuff out in-depth is a waste of time and you just duct tape everything to get it working.
Ephemera and arcana I've learned decade ago still serve me well today, even when it's outdated people mostly either reinvent stuff so I can recognise new stuff as a variation on an existing thing or build on previous solutions so I know the details and circumstances that lead to some developments and this lets me understand new things better as well (puts it in context).
>Ephemera and arcana I've learned decade ago still serve me well today,
I think the usual back and forth about developer interviews may have this thought as an underlying assumption; specifically people who can solve a red/black tree on the whiteboard at the drop of a hat must be filled to the brim with useful but potentially obscure knowledge. (Obscure to those who haven't majored in CS or a related field.)
It would be interesting to submit an ask hn "What is your so there I was doing x, y, z when being able to answer obscure interview question seventeen saved the day" story.
(That's not well worded but you get the idea).
It doesn't even have to be "from their prime" (and I don't like to encourage that ageism concept, now that we have hiring managers fresh out of school). I'm comfortable asserting that, at any age, they will probably be high-value, having enough background to have insights and see connections that others cannot yet, now with a lot of general wisdom besides. See Danny Hillis's writeup on Feynman at Thinking Machines. You'd just need to offer them a compelling work situation, with problems that interest them.
Heh, true, I just added "from their prime" because I know not all of them are still alive so would not add much to a development team in their current state.
> You'd just need to offer them a compelling work situation, with problems that interest them.
If you want to attract those kind of people and have them do their best work, then part of the “compelling work situation is to let them pursue their own problems.
Alan Kay:
” I don’t run CDG, I visit it. [Xerox PARC founder Robert] Taylor didn’t want to hire anyone who needed to be managed. That’s not the way it works. I have people on my list who are already moving in great directions, according to their own inner visions. I didn’t have to explain to these people what they would be working on, because they already are. Bret Victor has already hired four people that I didn’t know about. I wanted people to fund, not manage.”
And they all would have failed to get past the phone screen from the recruiter wanting to know how many years of experience they have had with "the XML" or "the Spring".
Can you give a concrete example of some topics it covers in breadth and how it would help me to read that book? FWIW I mostly program in ruby, go, elixir, and I program web apps.
Yes -- which is why you'd do better to read these books than 95% of the links on HN. These are books about how objects work and how EVAL is defined. These are the meat-and-potatoes of computer science. There's no "Linux distros, networking, web dev, dbs etc" here.
not really, like if you're broad then it means you get muscle memory for "any old shit". Like I'll happily blunder into language or tech stack because the implementation patterns overlap so much after you've juggled a few things.
> oh its one of these sort of things like xyz I did four years ago.
Of course the specifics are different but the muscle memory can get you through. I'd say the worst bit about it is that you often feel impostor syndrome pretty bad because in many cases you're never 100% sure about stuff like you might be in a speciality.
I believe any team needs a combination of both types i.e. people with breadth and others with depth.
Some people are just good at seeing the top view and how all of it will fit in most optimal way possible.
I am saying this because I can see abstract patterns from the top and what's wrong with entire project. But entire IT industry is looking for people with depth. So sometimes I wonder if there is need for people like me in IT but then again when I see a vast system I can immediately discern what could go wrong, possible bottlenecks or come up with better solution. This gives me little bit of hope.
I do tend to focus more on breadth, but I do go deeper on some subjects. However, I never give up breadth for the sake of going _Jon Skeet on C#_ level of depth. That, for me, is a waste of time[0]. I don't need to know a language or tool quite that deep. I can be very productive with a certain depth without touching bottom.
[0] Note: I'm not saying Skeet is wasting his time.
The other thing you need to be careful in with focusing solely on going deep on one topic is that that one topic can go by the wayside.
I've known people who were, in one example, arguably the world expert in performance on a long ago computer architecture. There came a point where no one cared any longer and I'm not sure to what degree he successfully moved on to other pursuits.
Another example is Y2K. A lot of consultants ended up defined as being Y2K guys and they didn't necessarily successfully transition to something new.
Not arguing that going deep is necessarily wrong but, if you do, you need to keep your eye on emerging areas that could benefit from your existing skills.
You can focus on breadth or depth depending on what kind of programmer (generalist or specialist) you want to be. Matt Klein (of Envoy) had a good thread about that on Twitter [1].
He focuses on depth whereas I tend to focus on breadth. Of course I have areas and technologies I know better because I have worked in / with them (computer vision, filesystem / DB replication algorithms, Lua, etc) but I try to expand my areas of knowledge so I can understand whole systems rather than become an expert at a specific thing. For instance, right now, I'm doing mostly Web front-end stuff, which is the part of the Web stack I know the least.
The problem with this recommendation is the complete obliviousness Alan has to the difference between the context HE brought when reading these texts to the context NEW developers bring. NEW developers (e.g. learned how to program after ~2005) will find very little to take away from such papers sadly.
Cool, "Starting Forth" is available for free on forth.com!
Makes me curious about SwiftForth [1]. I saw a bunch of other commercially available forth implementations in the past ([2] ?), but since Forth looks so niche I never got motivated enough to try Forth more seriously.
> The way to grow from this book is to deeply learn what they did and how they did it, and then try to rewrite page 13 in a number of ways. How nicely can this be written in “a lisp” using recursion. How nicely can this be written without recursion? (In both cases, look ahead in the book to see that Lisp 1.5 had gotten to the idea of EXPRs and FEXPRs (functions which don’t eval their arguments before the call — thus they can be used to replace all the “special forms” — do a Lisp made from FEXPRs and get the rest by definition, etc.).
Found it ironic that in a comment about Lisp, Kay forgot to balance his parens. :)
Joe Amstrong had a related talk 'A Guide for the Perplexed'[0] last year. He mentioned several 'forgotten great ideas' such as Linda Tuple Spaces, Flow-based programming, Xanadu and Unix pipes.
Computation: Finite and Infinite is one of my favorite books.
It's fascinating to see computation built up from the theory of neural networks.
Marvin Minsky is just such a deep thinker and writer.
For those who are interested I made the neural net system into a simulator:
The depressing things about reading lists is that it's hard to go through all of them. Many of the books list (SICP) take a long time to wade through, read, and program the examples. They are not "light reading".
Only at the beginning. I found the first couple of chapters around algebra to be a turn off. But once I got past that, I found it a lot more engaging.
(Not that there's anything wrong with those chapters. If someone happens to like them, great. It's your time. Read the book the way that works best for you.)
That’s not quite true, I remember going through SICP easily before I learned post-high school math (which included relearning some basic algebra) when I went on my own self guided CS course. The lectures on YouTube are particularly accessible to newbies too with basic math and programming knowledge.
It doesn't. There's a few math heavy exercises in the first chapter, and the math is generally explained as it goes along too. Except for the first chapter, it's pretty math-free.
That doesn’t make it not quite true. You may be gifted at the subject. I was not and couldn’t get through SICP. You need a mind for mathematics or the requisite education in mathematics before doing SICP.
You don’t have to read 100% of every single book. Even just going through the first few chapters of SICP (or other similarly dense, more theoretical text) would most likely be beneficial to those who have never worked through the material before.
Also, by reading the classics/greats, you get the style of their thinking—something missed in a summary of the book, or someone else's re-presentation of it. In training, what you are taught is the important thing; but education is in being exposed to ways of thinking characteristic of a particular field, and the styles of thinking of particular teachers/writers.
The constant recommendation of successful scientists is to "Go to the masters, not the commentators." It is the master who, by definition, has the right style, and often the commentators give the results without the essence—style!
— Richard Hamming, Methods of Mathematics Applied to Calculus, Probability, and Statistics, Prologue
> It starts with a version of John’s first papers about Lisp, and develops the ideas in a few pages of examples to culminate on page 13 with Lisp eval and apply defined in itself. There are many other thought provoking ideas and examples throughout the rest of the book.
Sounds like the MIT SICP course from the 1980s using scheme!
Alan kay is a big of Engelbart and I'm surprised it wasn't listed in his answer. Also, for anyone that's interested, a windows clone of NLS is available here for windows: http://www.ndma.com/resources/ndm8543.htm
Minus the "journal", many of the multi-user capabilities, and the "compiler compiler" programming system of NLS. still, it's interesting to play with.
It feels like a worse and more ridiculous version of Yahoo Answers. Half the answerers don't know what they're talking about and half are marketing departments.
I met him at a conference 10 years ago - I basically blew off the whole conference to sit at his feet in the lobby while he told stories and shared pearls. There were 3-4 of us, probably 30-40 years younger than him, and we were all nobodies, but he didn't care. One of my favorite experiences ever.
This is a great companion to "The Goal" and "The Phoenix Project," both of which use fictional narratives to illustrate best engineering practices in the context of saving a (fictional) business.
266 comments
[ 0.22 ms ] story [ 314 ms ] threadBoth Minsky and McCarthy seem like almost mythical figures in the book, and I don't think I could ever hold aa candle to them, but the next best thing is probably to understand their thinking. I think it's a bit easy for us to get caught up in the medium blog posts detailing a small segment of a new framework, when what we really ought to do to grow, is go back to the basics and understand them in-depth.
https://web.media.mit.edu/~minsky/papers/jokes.cognitive.txt
Abstract: Freud's theory of jokes explains how they overcome the mental "censors" that make it hard for us to think "forbidden" thoughts. But his theory did not work so well for humorous nonsense as for other comical subjects. In this essay I argue that the different forms of humor can be seen as much more similar, once we recognize the importance of knowledge about knowledge and, particularly, aspects of thinking concerned with recognizing and suppressing bugs -- ineffective or destructive thought processes. When seen in this light, much humor that at first seems pointless, or mysterious, becomes more understandable.
A gentleman entered a pastry-cook's shop and ordered a cake; but he soon brought it back and asked for a glass of liqueur instead. He drank it and began to leave without having paid. The proprietor detained him. "You've not paid for the liqueur." "But I gave you the cake in exchange for it." "You didn't pay for that either." "But I hadn't eaten it". --- from Freud (1905).
"Yields truth when appended to its own quotation" yields truth when appended to its own quotation. --W. V. Quine
A man at the dinner table dipped his hands in the mayonnaise and then ran them through his hair. When his neighbor looked astonished, the man apologized: "I'm so sorry. I thought it was spinach."
[Note 11] Spinach. A reader mentioned that she heard this joke about brocolli, not mayonnaise. This is funnier, because it transfers a plausible mistake into an implausible context. In Freud's version the mistake is already too silly: one could mistake spinach for broccoli, but not for mayonnaise. I suspect that Freud transposed the wrong absurdity when he determined to tell it himself later on. Indeed, he (p.139) seems particularly annoyed at this joke -- and well he might be if, indeed, he himself damaged it by spoiling the elegance of the frame-shift. I would not mention this were it not for the established tradition of advancing psychiatry by analyzing Freud's own writings.
Regarding multi-layer neural nets Minsky says they're uninteresting as they could be declared with enough complexity to basically reimplement any existing logic circuit. What made multi-layer neural nets interesting again was a multi-layer training algorithm.
There another interesting part, shortly after showing that single-layer neural nets can't implement the XOR function, Minsky shows that all that's required for a single-layer neural net to implement the XOR function is to add another column to the training set with specific values, effectively encoding the hidden layer back into the training set.
I eventually found my way to Minsky's class. It was nominally on one of his past books, but the class sessions often seemed to be him talking about whatever he was thinking about that day, as he worked on his next book.
Minsky's "ten-year grad students" and unofficials were also great. Two of them were especially personable, and would wander around the lab, and strike up impromptu technical conversations with random other enthusiastic students. Which seemed unusual among grad students of my dotcom era, and maybe it was more old-school greatness, like the Levy book.
http://www.softwarepreservation.org/projects/LISP/book/LISP%...
This was archived from http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf which now returns a 404 Error.
At least two of my items were on Alan Kay's list. The other being "The Mythical Man Month", especially the edition with the "No Silver Bullet" article, which a depressing number of people in our industry seem to not have read. So I don't feel like I'm too far off the mark.
These quotes about Gregor Kiczales and AspectJ https://en.wikipedia.org/wiki/AspectJ are good intro to MOP:
"In Lisp, if you want to do aspect-oriented programming, you just do a bunch of macros and you're there. In Java, you have to get Gregor Kiczales to go out and start a new company, taking months and years and try to get that to work. Lisp still has the advantage there, it's just a question of people wanting that." -- Peter Norvig
"I am reminded of Gregor Kiczales at ILC 2003 displaying some AspectJ to a silent crowd, pausing, then plaintively adding, "When I show that to Java programmers they stand up and cheer." -- Kenny Tilton
Seems simple when you first slap an annotation onto a class or method. But God help you when it stops working and you actually have to debug what it's doing. Figuring out what code is actually executing and what it's doing seems nigh impossible.
(Which is all to say, Lisp is still far superior, because there is a straightforward process for figuring out what kind of code a macro will generate, or to run a macro and look at its output. Macros can become complex and convoluted, but that's still nothing to the mess that annotations in modern Java frameworks create.)
There is no way to reason about the code without actually running it. You can not read the code and understand what it's going to do.
I am looking to spend another 4 months learning ML, which I likely won't apply in any way.
That's a year down the drain with ONE cloud provider and ONE way of doing ML. It's easy to completely waste your life like this WITHOUT getting better at your job.
Carry-over is far more limited than people make it out to be, unless you REALLY know a lot, but those people are rare.
Being 35 and having worked in IT for 15 years now and seeing the rapid acceleration into DevOps/Cloud/nix/Programming/Stacks I fear for my future. I want to learn a ton of stuff, but the vast amount of stuff needed to learn in order for me to move up in my salary bracket is stifling. AWS/Azure/+ the former I mentioned, then Python, YAML, Cloud networking. I'm good at some stuff, but the industry is just moving so ultra fast now it's hard to keep up.
I've been contemplating getting out of IT altogether because I'm not fully confident in career growth at this point unless I murder myself with study and ignore my family.
I've been a MS SysAdmin for 15 years, moving into nix devops (the new way of sysadminning) isn't easy.
Interestingly, earlier in my career, most of the developers I worked with were also capable at system administration, and could easily fill that role if needed.
The sysadmins during that time were quite capable, but had no desire, or an admitted lack of ability for a development role.
It is an interesting phenomena to observe.
Despite its clear fit with the current hotness of immutable systems and functional programming, I don't think I've seen anyone in for-profit industry on a Nix/NixOps stack.
I think this is completely true as well. To move past senior developer, you fall into one of these camps:
1. Very bright.
2. Spent a LOT of time studying or messing around with the right tech on your own.
3. Sell your soul, i.e. ignore (or not have) family/kids.
A lot of people from camp #1/2 don't understand that for most, #3 is the only option (in the short term). There is also the very real tradeoff of not going with #3 and risking declining job prospects/salary.
I think this is doubly painful for devs, because they are generally used to quick career progression / salary bumps, and then it stalls hard at senior dev.
What kind of job would you be aiming for?
Age-ism, of course. You can't be a 50yo senior developer.
It called consulting.
I'm not ignoring the fact that ageism is a real thing (it most definitely is), and it is more difficult for many older programmers to "keep up", but that doesn't mean that no one is doing it.
The best developer I've ever had the pleasure to work with was a 50-year old senior developer. He cut his teeth doing a lot of C/C++ stuff back in the day, but was also (pretty successfully) leading the company's adoption of Angular. If you have a sharp mind, and you don't get stuck in your ways, then people will be begging for you to be their 50-year old senior developer.
I've been a senior developer at the same company for 13 years. I feel that most of the time, I am progressing in my knowledge and experience, so, in my mind, I am making progress. It just doesn't seem that way on my Linked In profile.
Deputy Developer? Elder Developer? Doyen of Development? Development nestor of company X? Director of Engineering at Sub-sub-sub-sub-department that happens to be just your team? Level 20 Wizard? Does it even matter if it sounds good on LinkedIn?
Running contentious meetings and herding directors are difficult skills to even begin to practice on your own time, but navigating family life is probably as close as you can get.
The other thing I wanted to talk about is how I solve technical problems. The first thing I do is get a representation of what the problem is in my mind enough to where I can see a clear path forward. This leans on my ability to take a 10,000 foot survey of a problem space. My current role deals with microservice architecture. Microservices is right in my wheelhouse due to my better-than-average sysadmin skills.
But I end up having to learn a lot within a short amount of time. So in order to cut down on what I call the "sheer mass of information needed for mastery" any time I look at a new tool or tech, I make a beeline for the "architecture" or "concepts" page. This is where I work out exactly which concepts and which level of the architecture I'm working at.
I then use the problem statement and vision above to hone in on a perfect implementation. Then I look at the actual state of the system and work to bring it more in line with the perfect one.
I recently was tasked with getting one of our guys unstuck. He was having a tricky issue with aquasec that he'd been beating his head against for a week. It took me five minutes to understand the problem, then I went to my desk and spent twenty on obtaining a reproduction. I didn't want to redo his work, so I then asked him what happened when he did X and Y. From his answers I had a clear path to being able to demonstrate that it was aquasec throwing a false positive on a npm library, and was already in talks with our devops team about next steps. It took 30 minutes for me to move his issue forward.
I feel like this manner of solving issues with techs that you don't necessarily have full understanding of could revolutionize the industry. But I can't really grasp how to teach it. It looks like magic to people when I show it to them, they think it relies on years and years of experience. I mean, it kind of does, but I was able to avoid ever getting fully stuck on problems even as a teenager.
But stretching out the problem space and treating each barrier in turn, diving in a little bit into complex techs along the way, I don't see a lot of coders doing that. Instead they just kind of muddle around with what they know, believing they need perfect understanding of a tech before being able to solve problems effectively with it seems to be the norm. And we have this tech landscape where years of experience in technologies becomes the primary determinant behind how most employers judge candidates.
I think the increasing march of devops and other techs that purport to unite the whole world into one walled, splendid garden will eventually bifurcate the tech world into supermen who know everything, and the underclass who can only work in one garden. If that's not how things already are?
Maybe a secondary school for advanced coding or bringing guilds back.
I look at industry as a series of different waves happening where I just need to get on one so that I can find the next. A wave is going to cross the startup world before it moves into established business. If I time it right then I can hang in there for a while. It doesn't help with my anxiety, but I've done this before so I know I can do it again. I suspect I'd find the same pattern in a closer examination of your background.
There are very few people learning all of these technologies because time is required to learn the basics, as well as put it into practice within industry. That's deep learning. A lot of people are lucky to work in places that will put unproven technology into production. The number of places willing to take this risk is increasing because cool technology is a requirement for attracting top talent. If you are in a more risk-averse organization it may seem scary to move to a faster moving, less risk-averse one, but you might find they actually have more leeway for mistakes and learning.
I watch for particular patterns around how a technology is hyped and who is applying the technology. Thoughtworks publish their perspective (https://www.thoughtworks.com/radar) and I try to read this, plus other analyses to understand what direction things are moving in. You have to take a longitudinal view. It's not good enough to just compile your research and make a decision. You need to know how a technology has moved over time. Once you start doing this you start to develop some "spidey" senses when you see something at the top of HN - and you don't have a ramp-up cost each time you have to make a switch.
Other than that focus on a few fundamentals, including one programming language reasonably well. I'd strongly suggest learning Python and having an incremental two year development plan so you don't half-ass it. A lot of the Linux world is built on stable skills. Rather than focusing on AWS, or Azure networking learning networking and TCP/IP beyond a cursory level. There are a lot of folks building cloud infrastructure badly, slowly etc. because they don't understand these fundamentals. The references are old and boring like TCP/IP Illustrated Vol. 1.
That's a real problem. I had a few years when I worked on pretty cutting edge stuff so most of my learning was on the job and could be applied quickly. In my current job there is a lot of repetition and stagnation so you have to spend a lot of time outside the job learning stuff which you then never apply. This gets really old after a while.
nix devops is productizing/consumerizing the old way of nix sysadmining (at least for shops that did things the right way)
Saying that you can't move between cloud providers because you need to learn something new probably implies you don't understand the fundamentals constraining the design of e.g. databases provided by cloud.
They could just be branching into /r/iamverysmart territory and just parroting omgubuntu.
Lastly, having breadth of knowledge means you have learned how to learn efficiently. This is a significant force multiplayer.
An old-style hacker reads man pages, RFCs, specs, and programming books not to immediately know how to solve problems at hand, but to know what solutions are possible for future problems. It isn’t useful to know that the HTTP spec doesn’t specify a max header length or that the default setting on Apache is to only accept 8kb of headers, until it is suddenly extremely useful to know both things at once :)
* some would say “the other 90%”
Good luck with that, especially, but not only, with git man pages.
I tend to avoid reading these “just to know” but only when I need something specific. They are mostly torture. They could have been more useful to read but they presently aren’t.
https://git-man-page-generator.lokaltog.net/
"git checkout --detach [<branch>]
git checkout [--detach] <commit>
Prepare to work on top of <commit>, by detaching HEAD at it (see "DETACHED HEAD" section), and updating the index and the files in the working tree. Local modifications to the files in the working tree are kept, so that the resulting working tree will be the state recorded in the commit plus the local modifications.
When the <commit> argument is a branch name, the --detach option can be used to detach HEAD at the tip of the branch (git checkout <branch> would check out that branch without detaching HEAD).
Omitting <branch> detaches HEAD at the tip of the current branch.
git checkout [<tree-ish>] [--] <pathspec>…
Overwrite paths in the working tree by replacing with the contents in the index or in the <tree-ish> (most often a commit). When a <tree-ish> is given, the paths that match the <pathspec> are updated both in the index and in the working tree.
The index may contain unmerged entries because of a previous failed merge. By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. Using -f will ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by using --ours or --theirs. With -m, changes made to the working tree file can be discarded to re-create the original conflicted merge result."
Well yes of course.
If you try to have a wide breadth and a deep knowledge simultaneously, you will pay a heavy price. You will not have much of a family, you will not have other hobbies, you will not know much beyond CS, you will not even have time to use the vast majority of your knowledge to its full depth. There simply isn’t enough time. You will likely die as you lived, at a keyboard with your head weighing down on keys spamming them infinitely in a code editor, or slumped in a chair or bed with a technical book resting on your chest. Very few people will notice your passing, and the world will be no different for whatever knowledge you gained.
What we should strive for instead is “Just-in-time knowledge”, where the goal is to quickly become an expert on a topic you know nothing about right when you need to be. Many people first learn to do this when they get into debates on the internet, and then extend it into their professional careers.
1: Admittedly, the lottery of birth can make that more difficult.
This simply doesn't happen for anyone.
IT is a fast-moving field. Solving business problems takes understanding which good ways to do that are currently available, what limitations and dangers each approach brings, how would it interact with other things, etc.
You still need deep knowledge, but the most efficient knowledge is that of key principles, general approaches and ideas. A specific technology does not matter much, and can be mastered quickly enough, if you already are acquainted with the principles behind it. E.g. learn about FRP, and you will see how React, Elm, and Excel all work along the same lines.
What you end up with after some time is like a normal distribution: deeper knowledge around some area and various levels of acquaintance with a wide range of other things.
There are still areas where you can polish the mastery of one narrow thing to utter perfection: making pizza or coffee, sports like running or weightlifting, etc. You can keep practicing them to counterweight the feeling from the view of the sheer and constantly moving IT landscape.
The latter arguably runs somewhat counter to a lot of MVP, etc. approaches but recognizing the difference is still useful.
You just put into words what’s been bothering me about the way my team works. The “process” people—while well-intentioned—seem to think that by breaking inherently complex tasks up in just the right way, they can make the complexity go away.
Well, no. If that’s really the idea, why are you paying me so much?
Hear Hear! When talking to Junior Devs i always point out that they should take into account the Lindy Effect and invest some of their learning time into things that were here for atleast a century so they can get enjoyment out of their accomplishment for the rest of their lives.
You don't want to die without making at least ONE perfect pizza.
It's very useful to have enough exposure to things to be able to tell generally what's going on and to know what you need to look up.
Reading and practicing is key.
The majority of programming books are just ephemera and arcana and details that will be irrelevant in a year, or next month when the new version of the framework comes out.
Kay points to books, like the original Lisp Programming Manual, that will help you understand deep core concepts about computing itself, that will remain applicable no matter what framework or library you need to use tomorrow.
Take an Alan Kay, a McCarthy, Norvig, Abelson, Sussman, Armstrong, Steele, etc. from their prime and drop them into a software company where they have zero familiarity with the programming languages or tools currently being used, and within days or weeks they will be the most productive developer at that company by far. They will come up with simple, elegant, high performance and correct solutions to problems none of the other developers would have even considered.
Those are the kinds of thinkers you want to emulate, if you really want to write excellent software solving real problems in the shortest amount of time.
This should be on the wall of every developer's workplace.
Personally, I like this one.
Ephemera and arcana I've learned decade ago still serve me well today, even when it's outdated people mostly either reinvent stuff so I can recognise new stuff as a variation on an existing thing or build on previous solutions so I know the details and circumstances that lead to some developments and this lets me understand new things better as well (puts it in context).
I think the usual back and forth about developer interviews may have this thought as an underlying assumption; specifically people who can solve a red/black tree on the whiteboard at the drop of a hat must be filled to the brim with useful but potentially obscure knowledge. (Obscure to those who haven't majored in CS or a related field.)
It would be interesting to submit an ask hn "What is your so there I was doing x, y, z when being able to answer obscure interview question seventeen saved the day" story. (That's not well worded but you get the idea).
https://www.atlasobscura.com/places/st-anthonys-tongue
If you want to attract those kind of people and have them do their best work, then part of the “compelling work situation is to let them pursue their own problems.
Alan Kay:
” I don’t run CDG, I visit it. [Xerox PARC founder Robert] Taylor didn’t want to hire anyone who needed to be managed. That’s not the way it works. I have people on my list who are already moving in great directions, according to their own inner visions. I didn’t have to explain to these people what they would be working on, because they already are. Bret Victor has already hired four people that I didn’t know about. I wanted people to fund, not manage.”
https://www.fastcompany.com/3046437/5-steps-to-recreate-xero...
> oh its one of these sort of things like xyz I did four years ago.
Of course the specifics are different but the muscle memory can get you through. I'd say the worst bit about it is that you often feel impostor syndrome pretty bad because in many cases you're never 100% sure about stuff like you might be in a speciality.
Some people are just good at seeing the top view and how all of it will fit in most optimal way possible.
I am saying this because I can see abstract patterns from the top and what's wrong with entire project. But entire IT industry is looking for people with depth. So sometimes I wonder if there is need for people like me in IT but then again when I see a vast system I can immediately discern what could go wrong, possible bottlenecks or come up with better solution. This gives me little bit of hope.
I do tend to focus more on breadth, but I do go deeper on some subjects. However, I never give up breadth for the sake of going _Jon Skeet on C#_ level of depth. That, for me, is a waste of time[0]. I don't need to know a language or tool quite that deep. I can be very productive with a certain depth without touching bottom.
[0] Note: I'm not saying Skeet is wasting his time.
I've known people who were, in one example, arguably the world expert in performance on a long ago computer architecture. There came a point where no one cared any longer and I'm not sure to what degree he successfully moved on to other pursuits.
Another example is Y2K. A lot of consultants ended up defined as being Y2K guys and they didn't necessarily successfully transition to something new.
Not arguing that going deep is necessarily wrong but, if you do, you need to keep your eye on emerging areas that could benefit from your existing skills.
He focuses on depth whereas I tend to focus on breadth. Of course I have areas and technologies I know better because I have worked in / with them (computer vision, filesystem / DB replication algorithms, Lua, etc) but I try to expand my areas of knowledge so I can understand whole systems rather than become an expert at a specific thing. For instance, right now, I'm doing mostly Web front-end stuff, which is the part of the Web stack I know the least.
[1] https://twitter.com/mattklein123/status/1130206792175169536
http://thinking-forth.sourceforge.net/
Edit: Starting Forth also by Brodie would probably be a better “spec” for implementing a Forth.
Makes me curious about SwiftForth [1]. I saw a bunch of other commercially available forth implementations in the past ([2] ?), but since Forth looks so niche I never got motivated enough to try Forth more seriously.
1: https://www.forth.com/swiftforth/
2: https://8th-dev.com
Found it ironic that in a comment about Lisp, Kay forgot to balance his parens. :)
http://www.ibm-1401.info/Meta-II-schorre.pdf
At VPRI (Kay's research institute) they did this: COLA. (See also STEPS.)
http://www.vpri.org/
https://en.wikipedia.org/wiki/COLA_(software_architecture)
http://www.vpri.org/pdf/tr2012001_steps.pdf "STEPS Toward the Reinvention ofProgramming, 2012 Final Report"
[0] https://youtu.be/rmueBVrLKcY?t=1949
Especially if you are in any kind of project management role. There is simply no excuse.
More Lisp fun [2].
[1] http://www.softwarepreservation.org/projects/LISP/book/LISP%...
[2] http://www.softwarepreservation.org/projects/LISP
For those who are interested I made the neural net system into a simulator:
https://justinmeiners.github.io/neural-nets-sim/
http://gen.lib.rus.ec/search.php?req=Computation+Finite+and+...
alan kay is a big fan of his.
The depressing things about reading lists is that it's hard to go through all of them. Many of the books list (SICP) take a long time to wade through, read, and program the examples. They are not "light reading".
(Not that there's anything wrong with those chapters. If someone happens to like them, great. It's your time. Read the book the way that works best for you.)
The constant recommendation of successful scientists is to "Go to the masters, not the commentators." It is the master who, by definition, has the right style, and often the commentators give the results without the essence—style!
— Richard Hamming, Methods of Mathematics Applied to Calculus, Probability, and Statistics, Prologue
That gist is copied from this page on Victor's site: http://worrydream.com/#!/Links
It was discussed on HN in 2014: https://news.ycombinator.com/item?id=7578795
Sounds like the MIT SICP course from the 1980s using scheme!
Alan kay is a big of Engelbart and I'm surprised it wasn't listed in his answer. Also, for anyone that's interested, a windows clone of NLS is available here for windows: http://www.ndma.com/resources/ndm8543.htm
Minus the "journal", many of the multi-user capabilities, and the "compiler compiler" programming system of NLS. still, it's interesting to play with.
I met him at a conference 10 years ago - I basically blew off the whole conference to sit at his feet in the lobby while he told stories and shared pearls. There were 3-4 of us, probably 30-40 years younger than him, and we were all nobodies, but he didn't care. One of my favorite experiences ever.
This implies that he also blew off the whole conference. I wonder why he did that.
> There were 3-4 of us, probably 30-40 years younger than him, and we were all nobodies
I would hope that this isn’t the reason. Being famous and “holding court” like this is probably addictive.
https://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0...
https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...