How to Level Up

I was talking with a friend today who asked a question I’ve been asked many times before, which is “How do I get to the next level?” He’d learned programming, and he’s pretty good at it; but he knew he was missing a lot of core computer science, and he really wanted to know how to get what he was missing.

So I thought about it — and it’s a question I’ve thought about a lot before, because people keep asking. So if I was to suggest a good path for learning to be a good coder, it would likely go something like the sequence below. There’s probably room for fuzziness and reordering in the later steps, but I’d still recommend a lot of these, because they really do all make a difference, and they’re things I use every day.

  1. Learn an approachable high-level language. JavaScript, Python, Ruby, maybe even BASIC. Something that can do what you want, and where you get good quick feedback from it and where it’s easy to learn the basics. Write lots and lots of code in it. Make things. Learn to feel how the computer responds to what you say. Learn to debug your code when it doesn’t work right.
     
  2. Learn important algorithms and data structures. You’ve done lots with arrays and maybe maps or hash tables by this point; but now you need to expand your repertoire and learn about lists, trees, sets, set theory, heaps, graphs, and other ways of storing and organizing information. When you’re learning these, think a lot about things you’ve already made, and think about ways you could have done it better with the new tools in your toolbelt.
     
  3. Learn a flavor of assembly language. All of this stuff is high-level so far; but what’s underneath? How does the computer really work? This is your chance to find out. Assembly can be a bit hard, but once you understand it, the high-level stuff will seem more obvious. (Someday, I swear I will finish writing “Sean’s Assembly Intro,” and describe a way to learn assembly with a lot less pain.)
     
  4. Learn C. C is often called “high-level assembly language,” and after learning assembly, C will be surprisingly straightforward. You’ll realize that references are just pointers, and pointers are just numbers, and all of those data structures you learned are just different ways of looking at memory.
     
  5. Learn about compilers. Compilers seem like magic — but studying compilers will reveal the man behind the curtain, and show you what his limitations are too. This will also give you a set of new, very powerful conceptual tools for transforming data into other data — ways of thinking that many programmers never learn.
     
  6. Learn a strongly-typed language. Strong typing can help clarify and purify concepts that until now likely have been pretty fuzzy in your head. TypeScript, C#, F#, Haskell, Ocaml, SML, even Python with mypy. Spend enough time doing this that you, too, want to try to explain to everyone else what a monad is.
     
  7. Learn Lisp. Lisp has been around since before almost every other language in use today, and there’s a reason it’s still around. Even if you never write any Lisp professionally, learning it will change the way you think about coding — and you’ll realize just how much every other language you’ve studied stole from it.
     
  8. Learn about data compression. Data compression seems like magic — but it too is just a set of rules and patterns. You’ll learn about information density and entropy, and what lossless and lossy really mean, and ways of dealing with specific kinds of data, and what the limits are on how much data can exist; and then you’ll start to ask critical questions about how you’ve been storing data in your own software.
     
  9. Learn automata theory. By this point, you know how computation works, right? The machine executes instructions, or maybe reductions, and that’s all there really is to know, isn’t it? Learning automata theory will change how you understand computing in general: State machines, push-down machines, and Turing machines will give you powerful conceptual tools to explain how computers can — and can’t — work.
     
  10. Study others. Last, but not least, this entire time, you should have been not just coding, but also reading other people’s code — and thinking critically about it. How did they solve problems? What worked well? What didn’t? What techniques were good? What were obviously bad? Great novelists don’t just write books — they read lots of books too, and great programmers should read just as much code as they write.

There’s plenty of other stuff worth learning, of course! There’s scientific computing, networking, 3-D graphics, GUIs, operating systems, parallel computation, garbage collection, design patterns, image manipulation, and a thousand other categories of human knowledge. But if you do the ten steps above, you will at least have covered a lot of concepts that will keep coming up again and again and again, and if you’re a coder, very few of these — if any — will you ever regret having spent your time learning.

Comments Off on How to Level Up

Filed under Uncategorized

Firefox Tip

I switched from Chrome to Firefox about four or five years ago, and I generally haven’t looked back. Firefox has its issues, to be sure, but Mozilla’s pretty open about them, and Firefox is free in a way that Chrome isn’t, and runs everywhere in a way that Chrome doesn’t, and the work they’re doing on Rust in it is nothing short of amazing. I wholeheartedly endorse using Firefox, and I only open other browsers for those bad pages out there that insist on being “designed for Chrome” (shame on you, what year is this, 2002?).

So a pro tip for all you Firefox users out there: Like so many browsers, Firefox can get a little twitchy if you leave it up and running long enough: Its memory footprint grows over time, and sometimes its CPU usage will creep up until it’s eating the universe, especially if you typically have forty to a hundred tabs open (like me!).

So here’s a way to easily put a safe “Restart Firefox” button in the corner of Firefox’s window, without installing any Extensions or Add-ons

Continue reading

Comments Off on Firefox Tip

Filed under Uncategorized

Now with 100% more robots!

I’m leaving my role at Suvoda. I’ve enjoyed my time there, and I made some good stuff, but thanks to fairly strict nondisclosure policies, I haven’t been able to talk here much about my job like I could when I worked at HomeNet and Cox. I made some new friends at Suvoda, and some of us will stay in touch after I leave. I’ll still be rooting for Suvoda from the sidelines: There’s a need for well-run clinical drug trials, and society is the benefactor.

But — !

IAM Robotics reached out to me a few weeks ago, and after some whirlwind interviews, I accepted a new role with them as a software architect. I’ll be starting in June, and I’m really excited: I have a big responsibility to help scale their robots to the next level, and I absolutely intend to deliver on it. They have really complex challenges for the kinds of software work they do, and that’s absolutely my kind of problem: Crazy sky’s-the-limit challenges where there’s no perfect answer and every option is on the table. I’ll be doing substantial coding for them, but as the title implies, it’s a lot more design-focused than my job has ever been: I always did architectural work in all of my jobs before, just never as my official title.

I hope in the coming months that I’ll be able to post here more often on topics of interest. I’ve been doing a lot of interesting things, and I have a lot to say about them. As always, stay tuned — the best is yet to come!

Comments Off on Now with 100% more robots!

Filed under Uncategorized

Not so SOLID

I often don’t agree with Bob Martin.

It’s not that I don’t think he’s smart or capable or has had some good ideas; it’s really that I don’t see eye-to-eye with him on most things. For example, Test-Driven Development, to me, is a crazy backwards upside-down religion, not a defensible evidence-based set of techniques for ensuring you produce good software.

A couple of years ago, I was looking for a job, and one of the interviewers asked me if I knew the SOLID principles. I did, but not in the way they wanted to hear it. They wanted to hear me say, “Yes, ‘S’ stands for single-responsibility, ‘O’ for open-closed, ‘L’ for Liskov substitution…” They wanted me to regurgitate the acronym, because as cargo-cult programmers, they took SOLID as a message from the gods.

But it isn’t. SOLID is just some guy’s opinion. And today, I’m going to tear that opinion apart.

Continue reading

Comments Off on Not so SOLID

Filed under Uncategorized

The SpaceMonger 1.x Post-Mortem

(This is going to be a long story. But if you’d like to just skip to the source code, you’re welcome to.)

The Story

Twenty years ago, I was a kid in college.

Specifically, in the late ’90s, I was a college student living off-campus at Penn State, and I had a problem. The small video-game company my friends and I had started had gone bust, and I was switching back to DOS and Windows after some years of running only Linux on my computer. I’d just upgraded the DOS partition from Windows 95 to Windows 98, and the 2-gigabyte partition I’d installed it on had completely run out of space. I’d poked around at the folders in Windows for a few days, and tried using ‘dir /s’ at the command line, but there just wasn’t any way to get a holistic view of what the heck had eaten up my hard drive after installing Win98 on it: There wasn’t any way to see where all that space had gone.

Some time in 1997, after a month of futzing with my computer to no success, I was sitting in a barbershop, poking through one of the magazines, when I saw some nested rectangles with labels inside them in one of the advertisements, and I got an aha! moment. What if I could draw a picture of the hard drive? Using rectangles, like those ads? That were sized according to the sizes of the files?

I had rediscovered treemaps.

(Years later, I would find out that Dr. Ben Shneiderman had discovered the same idea about a decade before me. And it’s entirely possible that in the course of reading nearly every book, journal, and publication in the university on high-speed graphics during the video-game company days, that I’d seen an article by him the knowledge resurfaced. I don’t mind saying that he did it first, and maybe I subconsciously copied it!)

I ran back to my apartment after that haircut, scribbled some notes on my whiteboard, spent a few minutes working out the recursion — it was far simpler than calculating a BSP tree had been! — and I wrote what would then become SpaceMonger 1.0, in a single afternoon. (Warmongers seek war, peacemongers seek peace, and me, I sought disk space. It was a stupid name, but I didn’t have a better one.)

The code was clunky, but it worked, and it was fast enough for me to finally figure out what had happened to my disk. (Three answers: There were leftover installation files from Win98, and also some old forgotten images hidden away, and also Win98 was just big for the time.) I showed SpaceMonger to my roommates, and they thought it was neat and snagged copies of it. Over the course of the next week or two, I upgraded it, fixing bugs and adding features, making it nicer and more usable. By the end of that first week or so, there were a few buttons for zooming into folders, and for deleting files.

Figuring that nobody would really want software some college kid made in his bedroom, I posted SpaceMonger 1.3.0 here on my website. And, in truth, nobody really noticed for the first few months.

But then people started to download it in late 1997. They shared it with their friends. I got e-mails with questions. It got included on CDs of free software, and on websites listing free software. On a lark, I used my college French to translate it (badly!) when someone from France asked me a question over e-mail about how to use it, and thus by August 1998, SpaceMonger 1.4 was available in more than one language. I didn’t have a lot of time during my summer job to work on it, but I had enough.

Then school started up again. I was loaded up on classes, and biking four miles each way to campus from my new apartment, and SpaceMonger was mostly forgotten. I graduated in December 1998, and I took a big sigh of relief that college was at last over.

But I still had a lease on the new apartment.

Any normal kid would likely have cut the lease, taken the hit of three months’ rent, and gone out to find a job. But I’d done a lot of interviews near the end of my time at Penn State, and I was wholly convinced that the dot-com boom was not something I wanted to participate in. So I stayed in my apartment, paying rent with small consulting gigs, and spent a lot of my time researching. Studying. Thinking about what to do next.

I made a lot of weird software in those years after Penn State — like Mu, a replacement standard library for C++ when the STL was still in its infancy and seriously broken on almost every platform. Or WinBump, a bump-mapping texture-mapping tool that grew out of the video-game days.

But always there was SpaceMonger. I kept getting e-mails about it, fairly steady, asking for a new feature or a change or this or that, or just thanking me for its existence. And somewhere around early 2000, I realized that SpaceMonger had the potential to be my big commercial break, if I could make it good enough. I started coding on SpaceMonger 2.0, which became 2.1 for complicated reasons — but the full SM 2.x story is for another time.

SM 1.x managed to succeed because it was conceptually simple, easy to use, and free. It did exactly one thing and did it well. It was included by a bajillion download sites, and you can likely still find it online somewhere without searching very hard. Even decades later, I still get e-mails from people who love SM 1.x, people who liked SM 2.x but still go back to the original.

Open-Source

SpaceMonger is approaching 23 years old now — it’s older now than I was when I first wrote it! And it’s well past time to release the source code, so that a new generation of programmers can learn from my ideas and mistakes. There are some good ideas in there, and some awful mistakes, and in just a minute, we’ll talk about what were the best parts and what were the worst.

So the source code of SpaceMonger 1.4 is now posted on my GitHub account, released under the MIT open-source license. That means you can copy it, you can recompile and remix it, you can mutate it, you can reuse it, and you can even sell it — you just can’t claim you wrote it. (Also, you can’t complain if it doesn’t work, since it’s free.) It was designed to compile under Visual C++ 6 (i.e., Visual Studio ’98), but you can probably make it compile under today’s tooling with some effort. Good luck, and let me know how that works out for you if you try 🙂

At some point here, I also intend to release the source code of SpaceMonger 2.x. It’s much, much bigger and more complex than SM 1.x was, and includes a whole lot of neat stuff that the open-source community might want to steal. In particular, its treemapping engine uses some algorithms I’ve never seen elsewhere, algorithms that took me forever in front of a whiteboard to discover, algorithms that make it able to do almost instantaneous treemap layouts, layouts that were so fast that it could even do that cool animated zooming thing it did, even on a clunky old Windows 98 computer. I don’t have the energy to package all that up yet and release it right now, but it’s definitely coming… one of these years when I can get around to it.

SM 1.x, the Good, the Bad, and the Ugly

In the proper tradition of a software post-mortem, I’m going to say not just went well with SM 1.x, but also what went poorly. Maybe somebody can learn from it.

The Good

  • It had a beautifully simple UI. I’ll defend its UI to the hills: It opens to an empty window with just a row of buttons at the top, all greyed out except for the one you’ll want to click. It’s designed to be so obvious that it doesn’t need documentation, and I think it worked, based on how so many people in so many countries had no trouble using it, even if it was in a language unfamiliar to them. I read a lot of books on UI design in the mid- and late-’90s, especially Al Cooper’s About Face and Inmates, and SM 1.x resulted from a very conscious effort to be as simple a UI as possible. It’s still faux-3D and pixelly, like most software was at the time, but its UI is conceptually elegant even despite its age.
  • It did one thing and did it well. It scanned your disk and showed you which folders were eating it up. It didn’t have 10,000 features. It didn’t attempt to be everything to everybody. It had the one feature that everybody needed.
  • As it turned out, my problem was everybody else’s problem too. There’s a counter-intuitive notion in software that the best designs result from not designing for the many but designing for one. I built a piece of software that solved my problem and then I gave it away, and it turned out that a million other people had the same problem and wanted exactly that tool to solve it.
  • It was free. I can’t really overstate how much of a difference this made. Everybody everywhere could get it, and they did. I didn’t make a buck off SM 1.x, but even today it can be found all over the world. In some ways, it’s tempting to wonder what might have happened had I followed the open-source model with it: Would it have grown, or would it have floundered? (This was long before Git or Mercurial or distributed version control!) Would there have been other contributors, or would that effort have been a waste? It’s hard to say, but at least it was free.

The Bad

  • Building it on MFC. To this day, my opinion of “development frameworks” is colored by my MFC experience. I chose MFC at the time because it was this big development framework that Microsoft was proselytizing, this thing that everybody was using, that was The One True Way to code things for Windows.

    Boy, what a crock that was.

    MFC was a disaster, an architectural experiment gone wrong. A generation of programmers built stuff on it, but the moment that anything better was available (Java, VB, C#, the web), they rightly all jumped ship. MFC was originally built to be “wrapper classes” to make Win32 programming easier, but somewhere along the line, it developed Strong Opinions that everything should follow a Document/View model and be architected in a certain way, and everything went downhill from there. MFC is simultaneously overbearing and under-supportive: It insists you do everything its way, but “its way” doesn’t include most of the things you need to do in real-world software.

    I built SM 1.x entirely on MFC because I’d bought books on it the previous summer, and I spent most of SM 1.x’s development fighting with MFC’s constraints. If you study the source code, you’ll see that many pieces simply avoid MFC altogether and just access Win32 directly, just because of how bad and unusable the MFC classes were.

    To this day, I am still skeptical (and often rightly so) of “frameworks” that promise to do everything; as Spolsky said, every abstraction leaks; and my corollary to that would be that the bigger and more complex the abstraction, the worse its leaks will eventually be when they happen. The bigger they are, the harder they kabong.
  • Not continuing it. During SpaceMonger 2.x’s development, I stopped all work on SM 1.x. SM 2.x took years — it wasn’t released until 2006 — and meanwhile, there were bugs found in and features missing from SM 1.x, some of which would have been easy to do. I should’ve made some token efforts to keep it going, which would have kept rivals like WinDirStat from gaining traction in the interim. I lost a lot of good will in those intermediate years as people waited and waited and waited…
  • Thinking translation was a good idea. I got complaints for years after doing the translation to French in SM 1.3.4. The text was wrong, there wasn’t enough space, things weren’t quite right — if I knew then what I know now, I’d never have released it in any language except English, because I simply couldn’t support more than one language.

The Ugly

  • Not archiving well. The only source code that exists is SpaceMonger 1.4, because I just coded right over top of the existing source. Today, in a world full of Git version control, that’s nowhere near the problem it was then, but I should’ve made better backups of the code. Little did I know that twenty years later I’d still be talking about it.

Conclusion

So that’s it. SpaceMonger 1.x is long-last released as source code. It’s not perfect. It was written by a college student two decades ago, and the first version was less than a day’s effort. But it works, and maybe there are things to be learned in it by other programmers. In a future post, I’ll talk (again) about the algorithms it used, and explain how SM 2.x did it even better; but for now, having the source code and a decent story is likely good enough for one night’s efforts.

So have questions? Found a bug? Want a feature?

heh… now, at long last, you can handle that yourself 🙂

3 Comments

Filed under Programming

I hate being right

Some years ago, circa November 2016, I told my wife that under Donald Trump, we’d eventually reach the point where U.S. Army tanks would roll through Times Square in New York City to quell protests.

For the better part of three years, she’s told me, “It’s still not that bad.”

Well, would you look at that. Washington, DC is on fire, there are protests in every major city, the National Guard is helping the police to hold the riots back, and Trump has just called up every active duty serviceman to ensure “perfect law and order.” Tonight she told me with a very pale, sober face that she’s thought for three years that she was sure it was just an exaggeration, that there was no way Trump would send the military into the streets.

I hate being right.

Well, actually, I’m pleased to say I wasn’t right this time. There are no tanks in Times Square. Yet.

So let’s do some more prognosticating. If there’s still an Internet next year to read this on, you can all grade me on how the next six months play out.

  1. Trump will send Army servicemen into a city that doesn’t actually want them to quiet the protests.
  2. A shot will be fired by an Army serviceman. A civilian will die.
  3. That will change the nature of the protests from “A lot of policemen are racist” to “The entire government is out to get us.”
  4. The protests will get bigger.
  5. COVID-19 will get worse, thanks to all that close contact, and even more people will die.
  6. Trump will double down on the protests and summon more servicemen into the cities.
  7. People will fight back, increasingly seriously, and a lot of civilians will die in the crossfire. The summer of 2020 will be bad.
  8. Trump will declare Martial Law, even though that’s not an actual power of the presidency.
  9. The election of November 2020 will be suspended for safety concerns, even though the Constitution forbids its suspension.
  10. Trump will declare himself President “until further notice.”
  11. Every president selected in a year that ends in zero dies, usually by assassination.
  12. If there’s still a United States after all this, historians will easily rank Donald Trump as the worst president ever, because James Buchanan at least tried to prevent a Civil War, even if he failed badly.

I’m really, really hoping this timeline doesn’t play out. Maybe we’ll get lucky and it won’t. Maybe one of Trump’s advisers will manage to pull him back from the brink. Maybe the protests will burn themselves out before the military makes a mistake we all can’t go back from. Maybe this year won’t play out like 1968 on steroids.

I can hope, can’t I?

Comments Off on I hate being right

Filed under Politics

React Considered Harmful

This is one of those strange posts I never thought I’d write.

For the record, I love ReactJS. The principle of being able to build an entire website using forward-only data flow was sheer raw brilliance, and was a fundamental architectural shift in how website UIs work.

But —

Continue reading

Comments Off on React Considered Harmful

Filed under Programming

Making OO Better

I read “Object-Oriented Programming — The Trillion Dollar Disaster” recently, and I have some thoughts on it I’d like to share. I’ve written a lot of code over the years in a lot of languages, and while I agree with some of Ilya’s argument, I don’t fully agree that existing OO languages are inherently broken — just their current usage patterns are, and usage patterns, the way we think about using our languages, are something that can be fixed.

Sit back. This is gonna be a long one.

Continue reading

Comments Off on Making OO Better

Filed under Uncategorized

Decaf

I’m apparently a person who now drinks decaf.

I didn’t drink coffee at all for most of my life, and honestly for a long time I couldn’t stand it. But back in 2016 when my daughter was born, the options were “learn to drink coffee and survive having two kids,” or “die now.” Wisely, I chose coffee, and now, I can’t get through a day without a hit of caffeine in the morning.

This morning, after my first cup of coffee, I wanted something to sort-of maintain the alertness, but I didn’t want yesterday’s jitters from coffee, so I dared to brew a cup of decaf. I’m drinking it now, and it’s actually pretty good. This is a revelation to me: Not only have I taught my taste buds to tolerate coffee, but now I drink it just for the flavor.

Young me would be aghast. But young me isn’t young anymore. And here we are.

Comments Off on Decaf

Filed under Uncategorized

Hello, Suvoda!

I started my new job this week, working for a company called Suvoda, in Conshohocken, PA. They run clinical drug trials, which means that in a literal sense in my new job, I get to use advanced computer science to help cure cancer.

ROCK ON.

The place is really neat, and while I’m still getting used to it, I love the vibe there. We’re doing good things for the right reasons, and I get the absolutely delightful side benefit of working with a few old friends, too. The company is healthy and growing, and everybody’s been incredibly friendly. I’m looking forward to doing great things with their teams there and helping them to have no end of successes.




So why Suvoda? Why not somewhere else?

When I left my last job in April, I was looking for three things: I wanted to find a place (1) where the people were smart and dedicated, (2) where there was a focus on making good-quality software, and (3) where my job would be beneficial to humanity: Where I was doing good things for the right reasons, and not just to benefit the company’s bottom line. I interviewed at a lot of companies over the last six months, dozens and dozens of interviews, and while some jobs had some of those three criteria to varying degrees, Suvoda was the only one that really nailed all of them.

“Curing cancer” is a set phrase for “doing good in the world,” and Suvoda is literally in the business of curing cancer. I get the privilege to be a part of something that unequivocally makes the world a better place. My part is a small part of that whole equation, but if I can even slightly tie my work to somebody someday no longer suffering a terrible disease, I’ll be living a life that I can be proud of, and that matters: When you someday have to stand before Saint Peter at the Pearly Gates and he asks, “Well, so tell me, what did you do down there?” you want to have an answer far better than just, “I made lots of money!”

That said, there are a few downsides — no job is perfect! — but they’re small and manageable. The first is that the commute is longish, averaging about 45 minutes each way (best this week so far is 35 minutes, worst was about 70 minutes). I’ll be spending a bit more on gas than I used to.

The second is that since the commute is longish, my personal time is much shorter than it used to be: If you don’t hear back from me during the work week, it’s because we have kids to feed and water and put to bed in the evening, and 6:00 AM comes around pretty darn fast in the morning if you don’t get your keister heading to bed by nine. (Today’s a Saturday, and I “slept in” — I woke up at 6:30.)

And the third and final notable downside is that I’ve signed dozens of nondisclosure agreements this week, mostly for legal and safety and patient-privacy reasons — all of which are good reasons to be signing NDAs, and I’ve signed them quite willingly.

But that means I can’t tell you pretty much any more than I’ve already said about what I’ll be doing at Suvoda 🙂




But my job search is finally over, and I’ve found myself a new place to call home, a place where the people are nice, the pay and benefits are good, and the work is meaningful and the right thing to be spending my time and energy on. May all of you find such purpose.

1 Comment

Filed under Uncategorized