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.
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...
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).
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.
"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.
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.
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?
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?
Age-ism, of course. You can't be a 50yo senior developer.
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'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.
It called consulting.
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.
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.
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 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.
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.
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.
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.
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?
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.
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.
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
> 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 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.
They could just be branching into /r/iamverysmart territory and just parroting omgubuntu.
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.
This simply doesn't happen for anyone.
1: Admittedly, the lottery of birth can make that more difficult.