Going over headers:

Measuring myself against the water I swim in

I was reading The Water We Swim In: The Software Developer’s Mindset, and was taking some time to consider myself against the stereotypes listed in the article, and the exercise seemed rather illuminating. What follows is a self-inventory of how I measure up against those stereotypes.

Developers are In Love with Problems

So, I do like to solve problems, but I don’t know if I’m in love with them, per se? I’m definitely not scared of them, and am more than willing to tackle them head on, but I also have a tendency to avoid non-computery ones until I can think of an attack on them. I’m certainly not afraid of problems, per se, but I think I’m overall more intrested in solutions than problems as such. I think my motivation there is less about problems, and more that I think Janet code allows me to make things pretty, so therefore I want to make Janet code more accessible to other people).

A recent example of this dynamic at play for me is my involvement with Janet: There’s been a lot of problems that have come up in my usage and attempt to grow in my skill with it. But I’ve always had a mind towards an end goal (I want to be able to build anno-server). I’ve not fallen in love with any particular problem I’ve met along the way. A strong example would be janet HTTPS clients. Because of the difficulties of building libcurl on windows, I’ve written a library for using curl as a subprocess, rather than sitting down for however many days, and figuring out how to build CURL on windows. The destination is “I can write Janet to hit a website, and I can do it on windows”, not “Janet needs to have perfect libcurl bindings”.

Developers are optimistic about eventually fixing all of the bugs

Boy, I was like this when I was younger, I’ve since grown out of that into a much more less absolute viewpoint: Bugs matter as much as they impact users. There are some exceptions, I think that people generally under-consider security, as evidenced by the version number attacks on most programming-language package managers that happened recently. Concurrent systems will eat your code alive if you don’t build them right. Even if you do they still might, since you might build your code right for the wrong workload. It pays massive dividends to have an understanding of how your system is going to be used. But, if a bug can be worked around easily, and won’t destroy needed data, it’s more than fine to wait on getting it fixed.

Developers Qietly Contemplate, and then Turn the Model Into Code

I definitely know some developers that do this. It’s only a half-approach to how I do things, however. I’ve long ago gone past the point where everying I’m working on would fit in my head. These days, I’ll often try to build some code sketches to build out a model of what I’m making, and try to write some notes, or talk to people to validate my line of thinking, and to make sure I’m not missing a valid angle of attack. For Janet, these sketches often turn into tests, for C#, Linqpad scripts. One big help with Johnny Decimal has been providing an explicit place to put these little code explorations, so they don’t litter a /dev directory. I’d argue that being able to develop using a Journal, rather than keeping it all in your head, is a valuable skillset. Being able to build and reify code-intelligence also helps with refactoring, and tests can be good here, though I’m a long way from being skilled at using tests in combination with refactoring.

I do remember the distinct feeling from when I was first learning to code that I couldn’t just sit down and “write code”. I had to take time to build a mental map, and doing that at a computer wasn’t always the best use of my time. These days, if a problem maps well onto ones that I already know, or if it’s in a domain I’m familiar with, I can go from “here’s a problem” to “here’s 1-4 possible approaches to that problem, with tradeoffs, relative levels of effort, etc”. Getting to exercise that skill is a very satisfying feeling.

Developers Hate Repition

About two to three years into my career, I ran across Zed Shaw’s Learn the Hard Way series. I think that was my first introduction to learning through repeition, and I’ve long since taken the advice of “Don’t copy/paste code, re-type it” to heart. It’s still my preferred way to integrate code into a solution when I’m dealing with an amount of code that isn’t humungous, or effectively a black box. That hasn’t kept me from trying to automate certain problems (like time tracking at the command line, or organizing my knowledge) more than once. I’ve tried or built at least 5 systems for keeping track of my thoughts, projects and tickets. And I’m in the middle of another project to help with that. I’ve tried org-mode, two versions on a wiki, two versions on a tagged journaling system, and right now I’m using Johnny Decimal + Neovim. A few weeks ago it was Johnny Decimal + Kate, until I got tired of not being able to customize Kate easily.

All that to say that I have found myself drawn to trying to fix the same problem over and over in my personal projects, and have found the repetition both good for learning new tech, and insightful for trying to understand myself. In that past, I’ve definitely fallen prey to “If I can’t understand this in an evening or two, it’s not worth learning outside of work” a lot. I bounced off of Elixir and Phoenix at least once due to that, and is often why I bounce off of technologies that are hard to play with. This past two years, and after interviewing for “Computer Science, the Useful Bits”, my prespective has shifted a bit. I do look for oppurtunities to automate things, and I will always try to find tools to do arithmetic for me. (which is one of the reasons I’ve written my own CLI punch clock for work).

Developers Hate Obvious Inefficiency

This I definitely resonate with. I definitely get an itchy feeling at the notition of using alists (think using an array of pairs, where lookup is just iterating the array utnil you find the pair with the matching key), for example. As described previously, I have a strong desire for quick feedback. I don’t unit test enough in C#/.NET because of how much of a slog NUNit feels like compared to jpm test or rake test on a small project. I try to automate various processes in my day. I’m drafting this post in Neovim, where I have a 33-line init.vim that defines :Copy and :Paste commands because they are so much easier to remember vs the keybinds for copy/pasting to the system clipboard.

At the same time, I like to play around with things, and to build out an undestanding of the underlying pieces. Here, I think I’m a little bit more like how Noah describes Operators. I find much value in learning things for their own sake, and fiddling with my tools to either adjust them to be more pleasant, or just to see if I can do something. For C#/.NET, I find LinqPad to be an invaluable tool for that. REPLs are also good for this. I’m the person that got the Janet version of a bash_profile/irbrc added, so that I could configure the Janet REPL to be better for poking around. I like to try new editors, and new programming languages, just to see if there any useful tricks or tidbits I can take back to my regular work.

Developers Get a Huge Kick Out of Arcane Knowledge

I definitely enjoy learning about programming, and learning about obscure things. I like learning about new ideas or unusual approaches, or high-leverage concepts. Though I do like to learn about more than just computers in this space, and I really like to learn about people, and their stories. That might be a big distinguishing factor between and many devs: I am invested in understanding the people behind a tech, in the story of how the tech came to be, what the tradeoffs where, etc. I’m hardly the only developer to be interested in this, but I find the people I work with to often have other driving interests. I want to know why a piece of tech is the way it is, and often the answer involves a developer who knew about X, or didn’t have time to learn new language features, or had a favorite toy, but didn’t invest in understanding the tradeoffs of that toy.

Developer Love Complexity

I feel conflicted on this one. I like to work in and with systems that are understandable. I like the fact that all of my websites live on a single VPS, and are just reverse proxied off of nginx. But it took me running against the obvious flows to get there, and admin-ing as server like that has it’s own complexities. There, I trade off some developer ease by taking on some operational requirements. And I definitely am willing to add some complexity to a project to use what seems like the “right” abstraction. Usually, I’m trying to trade off busywork (repeating myself 3+ times), or making it possible to write elegant code, where the code can resemble its explaination. Simplicity/Complexity of tech is a very deep topic, however, and I definitely enjoy (for example), doing a deep dive on a legacy code base to try to understand it. I am more than willing to “cheat” to get things done more easily. In a way, I’ve been doing that for a long with when it comes to authentication for my side-project websites: I don’t think about auth, I just set up nginx basic-auth in front of the site, and code like the site will only have one user, which saves me a lot of time worrying about auth. But I’m also willing to lug around my own set of binaries to make Windows CMD.exe less painful.

Developers are Highly Specialized and Believe Things They Don’t Understand Are Easy

This is probably my strongest departure from the given stereotype. I could have turned out this way, easily, but for my parents. Before I’d written a single line of code, I’d had an interaction with an elderly neighbor. He was explaining how an internal combustion engine works, and I told him with all of the bluntness of an eight-year-old: “Oh, I already know that works, I read a book about it”. That got back to my mother, and she impressed on me that even when I think I understand what people are going to say, I should still listen, as I might learn something new, or an angle I hadn’t seen before. That value has gone on to shape me into a rather intense listener, and someone who has a strong curiousity about other people, and how they do what they do. I don’t seek merely to understand computing, or programming, I seek to understand people, their motivations, why they do things that don’t make sense on the surface. I’ve also tried to develope a strong skill for making space for people to talk about those sorts of things. If nothing else, my wife has greatly appreciated that I have the ability to just listen, without having to get an oar in.

All that to say that I don’t have a default assumption that anything is easy, unless I’ve learned it, and even then, I don’t assume that something I learned easily is something other people can learn easily. I’ve had too many counterexamples in both directions in life.

Developers Want There to be a Right Answer

I don’t know that I’ve ever totally had this mindset. For me, programming has always been more about “Is there a way that I can trick this computer/program into doing what I want”, rather than “Can I concieve of the Right Answer that is the Perfection”. That doesn’t mean I don’t weigh abstractions. It means that I’m often looking for an attack on a problem, and that I’m willing to take any solution, at least at first. It also means that I’m more than happy to kick things out the door once it’s good enough. At least things that are solutions for me.

Final thoughts

Overall, considering myself from these angles has been an interesting exercise, and I think it helps me understand where and how I fit into the culture of software development in general