Like a lot of developers, I kind of fell into it. I was lucky enough to have early access to Apple II computers at my school, and for those who don’t remember or who never found it - if you booted an Apple II with no disk in the drive, a flashing cursor appeared. It was an editor - a really, really terrible editor - for inputting and executing BASIC programs. I have no idea how I figured that out, but either someone told me or I managed to piece it together and I checked out a book of BASIC programs from the library and was able to painstakingly type some in through the editor. One line at a time. With no way to go back and change a line if you’d made a mistake.
Of course, the parser was looking for Apple BASIC, and the book I’d checked out was DOS BASIC, so most of them didn’t work and I had no idea why. The fact that I got any of them to work at all was a small miracle, to be honest.
But that experience set me up to understand that a computer wasn’t just something atomic and pre-delivered - it was configurable, editable, and most importantly, controllable. You just had to know the right magic incantations to control it. I’d always wanted to create robots, and as I went along, software development seemed like an obvious choice to get to that path.
I use either WebStorm or IntelliJ, depending on what I’m doing. I’m rather enamored of the JetBrains products (no, they don’t pay me to say that), with the exception of Rider, which consistently ate like 2G of RAM just sitting there. I’ve got a big honkin’ gaming laptop because sometimes you just need the 3D card, which runs Windows because unfortunately sometimes the client needs you to be using IIS. I’ve got two 27” monitors, plus the laptop screen itself, and I use an AutoHotKey script that boosts the multiple-desktop functionality of Windows enough so I can maintain three different desktops each with three screens, which seems to be enough for now. That usually means I have something like 40-50 Chrome tabs open, though.
I recently relocated in the building to be near my team, but it meant I had to leave my cube. Blocking visual distraction is an important part of how I work, so I did what I had to do to be productive.
You’re not seeing Samuel L. Jackson as Nick Fury on the other side of that cabinet. We’ve since decided that Larry the Cable Guy is an honorary Avenger (Captain ‘Murica, naturally).
At a gut level I really dislike this question, just like I get kind of frowny when people ask what stack I work with. The answer, to me, is kind of zen-like: “Whatever stack solves the problem.” Software by itself is like the tree falling in the forest - if there’s no audience to experience it and no problem for that software to solve, or emotion for it to create, then does it even really exist?
That said, the stack I reach for when I just want to produce something quickly without having to think about it much is Typescript/React, these days. On the other hand, I’ve done some robotics work recently and really enjoyed playing with the proprietary Pascal-based languages there; not because they were inherently fun, but because when you run them the robot moved. That’s a pretty visceral experience when most of the time your outputs happen in terms of pixels and bits.
(Me remembering how to solder, 2018)
These are my current favorites and I take no responsibility for the fact that library development on the front-end occurs at relativistic speeds:
React (reactjs.org) - Currently most of the front-end work I do is in React. It’s definitely a different animal from Angular - closer to some of the tenets of Backbone/Marionette (how’s that for a throwback?) but with all the modern niceties. Also plays nicely with Typescript.
MobX (mobx.js.org) - If you like React but hate the state management headache but ALSO think that Redux is a huge pain in the butt that results in significant boilerplate, then MobX might be for you! Get the benefits of Redux-like immutability and time-travel using events, while coding with your state like it’s a POJO.
Middy (middy.js.org) - As I mention below I’ve been doing AWS recently, and I just stumbled across Middy as a tool for handling common logic between lambdas in a way that’s not verbose. This one’s going in the toolbelt.
OMHUG (github.com/omhug) - Kind of cheating here, but this is the repo for the Omaha Mental Health User Group, a kind of synthesis of your standard user group and a peer support group. I started it for everybody in the tech and digital creative space to help support each other with some of the unique challenges in our work.
I’m pretty excited for Web Assembly, really. I feel like if we can actually get that sorted, it opens the platform up to languages that don’t end with “Script”. But then again, the web has been a series of expectation-defying shifts, so who the hell knows?
Other than that, I’m super interested in transcranial magnetic stimulation as a possible tech for changing things inside our skull without actually cracking into it. I’m excited for AR to finally become something real, if it ever actually does. I’m interested in where digital assistants wind up, and how AR will work into those, and how they’re changing everyone’s relationships to technology and each other.
I’d also love it if someone could find a good use for the blockchain other than wasting electricity and spewing carbon into the air. That’d be nice.
My workflow is scattered as all hell. When I’m noodling with something new, I try to glean what I can from tutorials or other “first steps”-type documents, but I usually have to take it off-road to actually learn what I’m doing. As long as I’m following other people’s instructions, the things I’m doing never seem to stick in my own head (for the people who are curious, this is called transactive memory and it’s super trippy). What that means is that for me to learn something, I really need to have a project or idea to use it on. If I don’t, I’ll never actually get around to learning anything. If I’m working on something for myself, this process usually involves a lot of starting, stopping, restarting, shifting around, and mostly getting very little done. I’m so bad about actually producing code on my own time.
On the other hand, if it’s for work, my ideal workflow involves a lot of collaboration up-front to discuss what we’re solving, to make sure we’re solving the right thing, and to make sure we know what the plan is. That plan never survives contact with the code, of course, but that’s part of being a developer. I care a lot about context, so when I’m coding I’m usually bouncing back and forth between high-level and low-level abstractions, trying to make sure the stuff I’m writing fits the overall picture, and that it still functions well and integrates into whatever test and build systems we happen to be using at that point.
In both cases, I know that I need a lot of time to let my subconscious brain chew on things, so I try to context-switch intentionally to let it have that time: taking walks, going and having a chat with another developer, chasing some thoughts down a rabbit hole, or cleaning my desk (infrequently).
I have been forcibly plunged into the depths of the AWS stack. I wasn’t expecting to enjoy it, but the benefits of serverless development kind of have me hooked. Of course, I say that, and I’ve been spending most of the day trying to successfully do some authorization to make sure clients’ data doesn’t get leaked.
I’ve also been learning a lot about group dynamics in the last couple months, as prep for a new conference talk. That has been a really exciting and hopefully rewarding thing to learn. I’m looking forward to polishing the talk and then trying to use the techniques to reap rewards on my own teams. As prep for the next conference talk, I’m starting to get my head wrapped around the various ways to bias an AI, cognitively or otherwise, and what we can do about it.
(Me at NDC Oslo, 2018)
A few jobs ago, I worked for a (no-longer-extant) company that was building an application for casino surveillance and investigations staff, to help them both correlate and connect patrons, and do basic analysis of their betting data to detect cheaters or other statistical anomalies.
I got to learn an incredible amount about how that world works, write some really cool statistical and analytical code, hear a lot of neat stories about how people had cheated the system (and been caught), and as a bonus I got a trip to a client site in Macau out of it. I’m still proud of some of the code we wrote for that app, even if I’d do things very differently today.
(I have no idea what face I am making here. This is IndyCode, 2017)
Impostor syndrome. What it is, who it affects, why it happens, and what to do about it. Too many entry-level devs feel like they’re walking among titans and they’ll never measure up, and that’s ridiculous. Ask any senior dev how many times they screw up daily, and if the answer isn’t at least one they’re either lying, or not writing any code.
No matter what anyone tells you, you can’t just leave your life at the door of your job. Even if you’re trying hard to be productive and cheery, when you have some large or dramatic situation outside of work, that has a heavy cognitive load which diminishes your capability inside of work.
You should never sacrifice your mental health for your job. Unless you have a title with a ‘C’ in front of it, you are not going to have the clout to “fix” whatever is wrong with your job. Do whatever you can to move on quickly. Yes, even if it looks bad on your resume.
The human brain is phenomenally complex and as a result, it is tremendously rewarding when you find out what you need to do to coax performance out of it. Take the time to figure out what you need to do to be productive - whatever that is. And then stand firm in demanding that thing, as long as it’s reasonable.
Learning enough to be experts at cloud-native programming is the current challenge - exploring and discovering while still managing to deliver value to clients has proven to be a rather tricky endeavor, even though we’ve managed to remain successful at it so far.
Beyond that, there’s the simple challenge of keeping on top of the sheer breadth of tech that’s out there now so we know what platform or language or framework solves which problem.
(Me, talking about learning at 200OK, 2018)
OSMI, or Open-Sourcing Mental Illness (osmihelp.org) is a non-profit dedicated to both raising awareness and gathering data about mental health issues in tech, and they deserve your money and/or attention.
If you live in the Omaha metro area, please drop by for an OMHUG meeting! It’s low on stress and high on connectivity.
I also actually just started a twitch (https://www.twitch.tv/arthurdoler) to stream me drawing slides and working on presentations. I decided to take the leap in order to make use of some of the things I learned about group dynamics and what audiences and evaluation apprehension do to our focus and performance.
You can find my site and woefully dormant blog at arthurdoler.com, and see what kind of talks I give, where I’ve given them, and where I’ll be giving them next. I do come and speak at companies and user groups, so if you’re located in a place I’m going to be (or want to help me get to where you are), hit me up!