2. I wish the build would have used something like an MCP23017 for IO instead of claiming so many RPi GPIOs. There's only a few (2-3 IIRC) GPIOs unused by the front panel, and the matrix LED/switch scan setup burns a ton of CPU
That is a Data General 6053, aka Dasher D2, terminal, with a trackball spliced in place of the number pad. The D2 was introduced in 1977, same year as the Apple II.
Totally agree (and also that’s the reason I think all CI ecosystems are a nightmare nowadays).
But GitHub Actions are somewhat portable: there’s the standalone act [0] runner, and the Forgejo/Gitea Actions (e.g. on Codeberg [1]) that use act under the hood and are pretty much drop-in replacement – they even use GitHub-hosted actions transparently. It might not be a 100% compatible standard, but it’s pretty nice. It would be nice for others to follow lead!
One book that changed me was reading Master and Margarita in Russian for the first time.
It was the first book I started reading I could not put down until the end. Gained a lot of appreciation for literature at that time.
The other book that I enjoyed and changed me was ‘The Wisdom of Insecurity’ by Alan Watts. I was a fan of Alan Watts works through his lectures already and it was wonderful to hear his ideas in writing for the first time.
I wish everyone read or watched Alan Watts lectures and books. The world would be a much nicer place if that was the case.
My favorite quote is by him:
‘We thought of life by analogy with a journey, a pilgrimage, which had a serious purpose at the end, and the thing was to get to that end, success or whatever it is, maybe heaven after you’re dead. But we missed the point the whole way along. It was a musical thing and you were supposed to sing or to dance while the music was being played.’
Couple of important lessons that will keep you in good stead for a long time:
1. Learn how to learn well, continuously, and sustainably. Tech changes rapidly. And you will want to hop from one domain to another, just for keeping things interesting and to move with markets. This is both a blessing and a curse. It is a blessing because you can start late and still be in the top percentile if you have the brains and work hard for it. It is a curse because you will be doing this no matter how many years of experience you have.
2. Hone your non-technical skills– caution: these are compounding over time (both good and bad habits) – being disciplined, thinking clearly, articulating clearly, being professional, being trustworthy, managing your physical and mental health, being dependable/reliable, having a growth mindset, thriving in ambiguity and uncertainty etc. then, honing your communication skills – effectively collaborating with people, give/receive effective feedback, do/get mentoring/coaching, working with cross-functional people, working with very seniors, very juniors, peers etc. read a lot, develop mental models, deeply craft your personal approach to first principles problem solving, to making tradeoffs/bets etc.
You can do the above all by yourself, through reading, and observing people from afar, and engaging with people (even strangers on forum like this one) in dialog.
I've been journaling for several years and have developed a template I fill out most mornings. After telling some friends about it, I put it in a public format and shared as a Google Doc that anyone can check out. I have a very long Google Doc with a more personal version of this template at the top of it, and I copy and paste it to bump down the prior day's journal and start filling it out.
Posting it here in case it's helpful for anyone who wants some structure around the journaling:
Never Split the Difference. It's about hostage negotiation. A lot of negotiation tricks don't work when dealing with irrational, desperate, insane people. It covers how to build rapport with these people, get them to talk themselves into supporting your argument, and just understanding people deeply enough for them to give you everything you ask for but walk away satisfied with the deal.
As another BDFL, I was disappointed to see that these were a set of principles about what curl/the curl project should be, rather than principles for how to be a BDFL. Obviously, they are related - how you conceive of the project is quite intertwined with how you intend to be-a-BDFL.
But the BDFL cannot by themselves satisfy most of the goals listed in TFA.
If I had to sum up my own right now, without much thought:
1. keep the project actually alive by ensuring there is clear evidence to all of continuous, significant development.
2. be respectful to all those currently involved, and to all who wish to become involved.
3. always remain open to the possibility that I'm doing something wrong, and eagerly seek out criticism that may reveal that to be the case.
4. notwithstanding #3, accept that I am the expert of experts in most senses, and have accumulated a lot of domain and application specific knowledge along the way; do not get hustled by newcomers.
5. notwithstanding #4, acknowledgement that newcomers may have ideas that hold the key to improving usability, discoverability, functionality and more. In general, strive to give their ideas serious attention.
6. Be nice. Be kind. Be respectful. Answer (most) questions asked of me personally.
7. When it is possible to financially compensate people for significant participation, do so.
8. Always acknowledge the contributions of others.
9. Promote the idea of my own humanity and that of all those involved, in order to encourage kind behavior and an understanding of what is possible (or not).
10. Always remember that it is other people who make my work possible, not me.
IMO, the above entity 'types' are mutually exclusive and collectively exhaustive categories (any concept or thing you can think of fits neatly into only one, and they should never be conflated or confused with each other). I think it is important to keep their identities very clear and very separate.
I.e., Task =/= Message and I think a system that recognises that is usually better (but, each to their own).
What made me understand these things the most, was setting this up just for myself.
For example host your own instance of Zitadel, Authentik or whatever you find most appealing.
Tinker a bit around with it. Then use that instance to authenticate yourself somewhere, i.e. another service where you can set up your own oauth provider. Take a look at the API requests, take a look the code of some OAuth implementation, for example in projects like Gitea, Nextcloud.
May not be it for everyone, though I really like learning by doing.
I really enjoyed reading his book Ghost in the Wires. It is the story of Mitnick’s hacking career, from the start in his teens, through becoming the FBI’s most wanted hacker, to spending years in jail before finally being released. It’s a fascinating book that at times reads like a thriller. One of the things that struck me when reading it was how often he used social engineering to gain access to systems.
Unix: A History and a Memoir, by Kernighan was a good quick read. It's probably more history than technical information, however the material that's presented is still in use across many unix-based systems. I came away from this book with a much better sense of the ideas behind many of the tools I've used all my life in terminal environments across multiple systems.
I was gifted the 48K when I was 6 yrs old - it changed my life. I am here because Sir Sinclair built a machine whose setup instructions said:
Now that you have set up the computer, you will want to use it. The rest of this
booklet tells you how to do that; but in your impatience you will probably already
have started pressing the keys on the keyboard, and discovered that this removes
the copyright message. This is good; _you cannot harm the computer in this way._
Be bold. Experiment. If you get stuck, remember that you can always reset the
computer to the original picture with the copyright message by taking out the '9V
DC IN' plug and putting it back again. This should be the last resort because you
lose all the information in the computer.
"You cannot harm the computer in this way."
That single sentence started a life long journey. I doubt I would have been bold enough at that age to mess around with one of our most valuable possessions.
I hate gym too (also mid 30s), and use the hate as a tool. I hate it so much, that nothing will stop me from going, because I'm always at the lowest possible desire level anyway. I don't care if the weather is bad, if my mood is bad, or anything else. I just deliver myself to the place no matter what. For over 13 years now.
(People who like gym risk not going when they don't like it. I have no such risk. I'm not tethered to liking.)
But here's the real trick: if you can afford it, get a personal trainer.
Pick a cadence (e.g. Mon/Wed/Fri or Tue/Thu/Sat), deliver yourself to the location no matter what, and let trainer take over from there.
- https://news.ycombinator.com/item?id=24972611 (about consulting and clients, but you can abstract that as "stakeholders", and understanding the problem your "client", who can be your manager, has.)
- https://news.ycombinator.com/item?id=24209518 (on taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable).
- https://news.ycombinator.com/item?id=21427886 (template for taking minutes of meetings to dispatch to the team. Notes are in GitHub/GitLab so the team can access them, especially if they haven't attended).
- https://news.ycombinator.com/item?id=26123017 (fractal communication: communication that can penetrate several layers of management and be relevant to people with different profiles and skillsets)
- https://news.ycombinator.com/item?id=26179539 (remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align)
There's a reason why MusicBrainz SQL schema looks like what it looks like, after years of careful simplification to achieve an optimum approximation of reality.
10+ years ago at Zvooq, during the golden age of music metadata and recsys startups, we tried to really solve entity resolution in the domain. I've never seen another streaming service make an honest attempt at this, even at Spotify with their 2014 acquihire of the Echo Nest. You still get Utada and Hikaru Utada as ~completely separate entities
New job, lots of, to me, low hanging fruit ripe for automation and documentation. The team has been adrift for a long time and all the juniors just accepted broken processes as facts of life.
Every time I have someone walk me through the completely undocumented process for x, I take notes and mark the best candidates for automation.
I then go through the process a second time, adding all the api calls and semi-automate the process so instead of logging into four different consoles in the browser hunting for values and setting minor things in different places, you can up front declare seven variables, and just copy/paste chucks of code that will perform all the steps for you. You are still acting as the error handler.
For low frequency tasks, it usually ends there. For high frequency tasks, I take the time to add error handling so it can just be part of a pipeline.
It's crazy to me that the team has put up with these processes for so long, I've been turning tasks that used to take 4-12hours and highly error prone and turning them into well documented code copy/paste jobs that takes about 15 minutes from start to finish, the vast majority of which is waiting for a build pipeline to finish.
Blind person here, happy to answer any questions. I'm speaking from the perspective of someone born blind, so whatever ends up working well for me might not work as well for someone just losing their sight, though I tried to take that fact into account.
The most immediate suggestions that come to mind are:
1. Learn to use a screen reader. You don't need an expensive one. NVDA on Windows, Voice Over on the Mac and Orca on Linux are the way to go. NVDA is probably the least quirky and easiest to find resources for. I'd recommend against Orca, while it can be used, we all know how tricky Linux on the desktop can get, and throwing a screen reader into the mix doesn't help.
2. Forget about the mouse. Screen reader users use the keyboard exclusively. Try disabling the screen too, many sighted users who practice with a screen reader end up relying on what they can see, which makes things more difficult.
3. Accept that inaccessibility is a fact of life, and it has to be worked around. Not all tools are accessible, and some are more accessible than others. If you're looking for an accessible IDE, Vs Code is great and constantly improving. Emacspeak exists, but I don't actually know anyone who uses it, and I know quite a few blind people in tech. Some things that you're now doing through a GUI are best done via the command line, Git is a good example. Programming tools usually aren't the problem, it's everything else that causes issues. Slack and Zoom work great, for example, but many smaller collaboration tools don't.
4. Not all areas of programming are equally accessible. I can't imagine a blind dev working exclusively on the front end, where there's a lot of CSS involved, and where you have to look at Figma designs and debug issues solely based on screenshots. Backend stuff is much more accessible, same with lower-level systems programming. Dev Ops is very much a mixed bag.
I'm happy to answer any further questions either here or via email, my HN username at gmail dot com.
int __THIS_IS_NOT_A_PLACE_OF_HONOR()
# no highly esteemed deed is commemorated here.
# nothing valued is here.
# What is here was dangerous and repulsive to us.
# This message is a warning about danger.
# The danger is still present, in your time, as it was in ours.
The Idea Factory, written by John Gertner, covers the almost inconceivable amount of innovation that came out of Bell Labs from the turn of last century to the 1980s. The names of the people who worked there reads like a text of 20th century physics, electrical engineering, and computer science.
I feel you Man! There are no quick answers but there certainly is a "Discipline" which if adopted can effect change.
First off, DON'T quit your job without having another already lined up. "A Bird in Hand is worth two in the Bush" and all that.
The "Discipline" comes from the "Yoga Sutras of Patanjali" which you can freely adapt to your life, like so;
- Yamas - Regulate your interaction with the external environment. Change what you can and ignore (completely from your mind) what you can't. Make a list of both.
- Niyamas - Setup personal habits to automate your daily needs. These are things like maintaining fixed work hours, eating at proper time etc. Make a list to follow.
- Asanas - Daily Physical exercise (whatever suits you).
- Pranayama - Daily Breathing exercise (learn to slow down your breathing and breath more deeply)
- Pratyahara - Practice withdrawing your mind from unnecessary things.
- Dharana - Practice repeatedly focusing on one thing.
- Dhyana - As a consequence of the above, Concentration on the object of study arises and the mind becomes steady.
Note that the above listed activities must proceed in parallel and not sequential.
You have to Act and Do and not merely Read and Think. But the latter provides the fuel for the former. So in that spirit read and adapt what you need from Yoga and Western Psychology: A Comparison by Geraldine Coster - https://archive.org/details/in.ernet.dli.2015.189086
A couple of things:
0. The physical quality of this build is out of the world good. PCB, plastics, switches, it's all amazing
1. The software as provided has a pretty old school build process (part of the charm?). I tightened up a bunch of it and dockerized it at https://github.com/mtrudel/pibox/tree/main/pidp11
2. I wish the build would have used something like an MCP23017 for IO instead of claiming so many RPi GPIOs. There's only a few (2-3 IIRC) GPIOs unused by the front panel, and the matrix LED/switch scan setup burns a ton of CPU