Keeping up with big shifts in tech

They say that developers always need to be learning. There’s seemingly endless articles on the topic, and most advise how to keep up with all the fast-paced changes of the tech world. But paradigm shifts happen while you’re busy making pull requests. What do you do when suddenly everyone around you is shouting about functional programming when you’re happily plugging along writing C++? Or when your beloved back-end language is suddenly making moves to the front end? Or when a JavaScript library suddenly seems like it’s taking over the world? How do you flow with the times as they slowly, almost imperceptibly shift beneath your feet?

This month, The ReadME Project Senior Editor Mike Melanson talks to a few developers to get their thoughts on how to keep up (or not) with the times.

Nyah Macklin serves as the Developer Evangelist for Couchbase during the day, and teaches non-binary and women engineers to code at G{Code} non-profit at night. Previously, they were the fourth engineering hire at Suborbital Software Systems, where they built the company’s flagship products. Their interests include the equitable use of data, using #tech4good, and open and free software for all.

Damien Katz is currently working on a new cloud-enabled fork of Oracle MySQL, and is best known as the creator of Apache CouchDB. Written in Erlang, it won him Erlanger of the year in 2008. He was CTO and chief architect of Couchbase, created the JSON full-text index and query system Noise, and most recently worked on Amazon Aurora for MySQL.

Justin Searls is the co-founder of the consulting agency Test Double. His life’s work is figuring out why so many apps are buggy and hard to use, how teams can promote collaboration and trust, and whether it’s possible for organizations to uncover repeatable approaches to creating high-quality systems.

Mike: What was the first paradigm shift that affected you as a developer?

Justin: I started building websites in the mid-90s when everything was basically static HTML. Around 2003, there was an article at the top of Slashdot about how Ajax was this new design pattern made possible by Internet Explorer’s XMLHTTPRequest API that had otherwise been used for nothing interesting. The article had a little proof of concept, and when I saw it, I immediately hammered out my first single page Ajax Javascript app in like three hours. The experience of clicking on a drop down and watching it populate, or watching the page change in some way by fetching new data, was so entirely foreign to my definition of what the internet was. The web was just documents before. I could suddenly see my entire career unfold in front of me.

It was dreadfully obvious, in exciting and terrifying ways, that this document model would be abused into becoming an application runtime. It was a lightbulb moment. I caught the wave and I rode it, and it really defined my entire ideology as a developer. I had four years of traditional computer science doing C, Java, and back-end stuff before that, but suddenly I was hyper productive and shipping way more meaningful stuff with these cool new Ajax web applications.

Nyah: When I was growing up, the tech field was not financially accessible to me. I come from a low-income background and I’m a career-changer. There was a basic understanding in my community that tech was for wealthy folk, whether that’s hardware or software. I didn’t have a laptop growing up, or go to school for computer science or anything like that. I did a boot camp called Resilient Coders, which pays people to learn the skills to become software engineers.

I’m going to take this question into a slightly different direction and say that the biggest paradigm shift that impacted me is the shift toward the expectation that all software be free or inexpensive. Software used to be sold on CDs and the cost could vary widely. Now, many developers will not touch a piece of software unless it has a perpetually free tier. That is now the norm. That allowed myself and so many engineers who did not grow up with the ability to spare a few dollars to spend on hosting fees, for example, to build software and advance our careers in the field. Free and open source software is a big part of that.

Damien: In college, I was thrown right into the fire with an “Intro to C++” course. I loved it so much that I changed my major. I would run to the computer lab after every class and lose track of time because it was so much fun. Object oriented programming (OOP) was really hot at the time, and I really bought into it. But I ended up overcomplicating a lot of code in an attempt to adhere to the OOP paradigm. After several years, I started to realize it just over complicated things, and that being dogmatic about programming styles, paradigms, or processes is very limiting. Looking back, I cringe at some of the code I wrote. I was trying to really shoehorn things that would have been much simpler had I just made that portion of it not object oriented.

Mike: What did you take from that experience? Did it change how you reacted to future shifts?

Damien: After starting out with C++ and OOP, I went the opposite direction and dove into functional programming, because it simplifies things so much. When I was writing CouchDB, I needed to deal with concurrency, and I kept hearing about Erlang, and how good it is at concurrency and making that work safely. So I spent maybe two weeks playing around with Erlang and everything clicked. I’d planned to just write a portion of the project in Erlang, but then I threw away all my existing C++ code and wrote everything in Erlang. I was ridiculously productive. I started to see that functional programming has a tight analogue to OOP styles of programming—it’s just a lot simpler. Joe Armstrong, the creator of Erlang, said that often in object oriented programming, what you wanted was a banana, but instead you get a banana being held by a gorilla and the whole damn jungle. With functional programming, you get very simple types, and a rich library of functions that can operate on them; you just get the banana.

Nyah: There are so many different shifts that are happening right now—decentralization of identity, crypto, AI—you feel like you need to hop on because you’re going to miss out. The ground is so unstable in this field if you are constantly being upended by the newest technologies being released. This field is always changing. The most important lesson I have learned is to remain flexible. At one point, React was the most in-demand engineering role. Then everyone thought crypto engineering roles were going to take over. Now it’s AI and ML roles. If you stay grounded in your abilities and skills, and you take up the willingness to be flexible as things shift, you will come out a stronger engineer.

Justin: When you’re a software developer, you’ll inevitably be surrounded by multiple tools and languages that are at different stages of their lifecycle simultaneously. If you have an awareness of where a tool is in its lifecycle, you can take advantage of that to do what you want to do.

For example, back in 2011, I had a client who did everything in Java and had to approve any new dependency, design pattern, or architecture—and they would always say no. But once, I was under a really tight deadline and asked if I could use sammy.js. This was before real frameworks for building single page JavaScript apps had really emerged, and their reply was, “Oh, nobody cares about JavaScript.” I realized that it was so early in its lifecycle that they didn’t even perceive the threat yet, that JavaScript would seize control. We built an application that essentially did an end run around all of the Java stuff, and it gave us this modern, fast iteration where we got to directly work with the customer. By the time the IT department figured out what we had done, the customer was already in love with it. It was a case of thinking about each shift, not as an isolated moment in time in the zeitgeist, but as just one wave in a sea of trends at various stages in their life cycles. There’s always lots of little waves cresting and falling simultaneously.

Mike: How do you keep up with these sorts of changes, and decide whether something merits adoption or is simply a passing phase?

Nyah: As a developer relations practitioner, it is imperative to stay abreast of the various trends, changes, and trajectories that occur within the field. My role demands I keep my finger on the pulse of my community—I am also a developer community builder as much as I advocate for their needs. When I am deciding what I should personally adopt, I focus on what I find interesting about a certain technology. Does it increase my developer productivity, does it improve my life at all, who built this product, and what do I believe is the future for such a product? Can this product be used #forgood, or was its data gathered in an inequitable way? Who can this software negatively impact? Once I am able to answer most or all of those questions, I’ll choose whether to adopt it or not.

Damien: With my general interest in programming and software engineering, I can’t not keep up with it. I browse tech sites like many people scroll social media. I tend to take a greater interest when it’s some new framework or scripting language that really makes you think about things differently. But too often, there’s too much new technology coming out. You can’t learn them all, otherwise you’ll just have a smattering of information about a bunch of things and an expertise in none. When you really have focused on one thing for a while and it becomes second nature, and then you can think in it and solve problems, that’s where you want to be. If you’re constantly chasing the next shiny new thing, it’s hard to become that.

Justin: I don’t read tech news, listen to tech podcasts, or watch tech videos. Instead, I come up with these little projects to do something new or cool or useful. Once I decide I’m going to invest a little time into it, that’s when I start searching for the best tool to do the job.

If you only search for tools for tools’ sake, or only track what’s trending, it can be a case of the tail wagging the dog.

But if you have something you really want to just force into existence and you use that to determine which tool is best, instead of just who’s most loudly promoting the cool tool of the day, you’ll end up spending 100% of your time on something you actually wanted to do. It’s always these little side hobby projects and curiosities that lead me to discover stuff.

Mike: Have you ever adopted when you should’ve passed, or vice versa?

Justin: I made a conscious decision to pass on React. I later came to regret that because it resulted in me fading out of relevance in the JavaScript community. React was clearly a small library solving one problem, and the entire world adopted it overnight as if it were a full-blown application framework. I just knew that that impedance mismatch was going to result in more bloated apps and buggier user experiences than anything we did in jQuery. I feel like I was 100% right about that. But still, sometimes I wonder if I had stayed in the game and kept riding that zeitgeist, whether I would have been able to make a meaningful difference, or contribute in some useful way to that conversation. Ultimately though, I think React was just too popular for its own good, and I probably wouldn’t have made a dent. So, I’m personally happy I avoided a lot of that churn and pain.

Nyah: Yes, absolutely. I attempted to avoid React and the newer development of React Hooks as long as possible, because when it first came out, I didn’t really understand it. I was trained as a Javascript engineer and implementing changing states with React was such a foreign concept to me. However, I think that avoidance definitely kept me from growing as an engineer. These were brand new developments in my field that would change the trajectory of how many sites would be developed going forward. But hindsight is 20/20. Eventually, most of my development experience centered around React. And being flexible showed me that I can develop expertise in something brand new and that’s not going to completely wreck my life or career. Flexibility is a muscle that I think is extremely important for engineers, because engineers who’ve been in the game for 20-plus years are now doing completely different work with completely different products than what they were doing when they first started.

Damien: I often wonder about my choice of Erlang. When I adopted it and went the route of functional programming, it allowed me to be ridiculously productive, personally. I was able to work so much faster than I did in C++. But, some of our competitors were using more mainstream languages, and they had access to better tools and more developers, communities, and libraries. So I started to question my decision. They do say hindsight is 20/20, but I don’t think that’s necessarily true. I don’t know what would have happened, had I stuck with C++. I might have gotten so bogged down in the details of concurrency and all that stuff that I might never have built something fast enough. I was living off savings then. At the same time, Erlang’s syntax is bizarre, and it can be too much to ask people to learn. It’s way too different from what they know—I gave up the first time I tried to learn it because it was so weird. So choosing Erlang might have been a bad choice for the project as a whole.

Mike: Once you begin to adopt something personally, is there a point when you try to convince others around you?

Nyah: Folks will find that I am seldom the person telling a team that they have to implement certain software. I understand that tech comes in waves. And it is important to understand the impact of that particular dependency on your stack. How many engineers are using this product? How long has it been supported? How often are the maintainers closing issues and improving the code base? How much does it cost? How are the developers being funded? All of these questions should have some sort of answer before you adopt a particular software, so these are the questions I ask before thinking about whether this would be a worthwhile investment for my team and the company.

Damien: I rarely spend a lot of time trying to convince others. Once a team has settled on tech, it’s worse to change horses for something slightly better. As engineers, we tend to believe ourselves to be these hyper-rational, logical people. We believe that our desire to use a certain technology isn’t an emotional thing, it’s because it’s the right thing. And then we get into these arguments about different paradigms that end up being more about keeping our ego intact than the technology itself. I’d rather go with the flow. It’s rare that you adopt some new technology that just blows away the productivity of the previous champ. It’s usually very incremental. I don’t waste time arguing. Instead, I just try to bring in aspects when appropriate.

Justin: When I adopt something personally, the first person I need to convince is myself. I have this hard-charging approach to learning new technologies where I try to solve a really challenging problem, and I need to pick a new tool or approach because the old way no longer suffices. I pick a really hard problem and aggressively attack it, usually from an angle that the tool doesn’t expect. Immediately, that raises a bunch of questions that have no answers. I like this approach to adoption, because it forces me to use the tool in anger. Every tool certainly is going to do a Hello World demo really nicely, but if that’s why you adopt it, you don’t actually know whether or not it’ll stand up to scrutiny. If I’m able to really kick the tires on something, by using it in a way it doesn’t expect to be used, and it still passes the smell test, then, and only then, am I ever ready to endorse it. And as a result, I don’t end up endorsing very many things.

Mike: Do you have any other advice you would give to newer developers still trying to find their balance?

Justin: There’s always going to be a new shiny thing that other people are excited about, and if you spend your entire career picking up and moving on to the next thing, you’ll never actually spend sufficient time in the present moment digging in and solving hard problems. You have to resist the idea that the grass may be greener somewhere else, because it almost never is.

Nyah: Don’t be star struck by the number of different options out there right now, and by how drastically things are changing. Stand in your knowledge and know that you are capable and brilliant. Focus on the fundamentals, whatever those fundamentals are for you, and find a space where you can grow to become the person people think of for that particular tech stack or piece of software. Don’t be afraid of the ever changing waves of this field because that flexibility allows you to become a much stronger technologist. We are all rooting for your success.

Damien: Don’t be dogmatic and get too married to any style, paradigm, or methodology. They all work, and they all don’t work. And success really has a lot to do with the team and the team cohesiveness and how well they’ve bought into whatever it is. The culture and psychological safety in the team—those are the kinds of things that actually make projects succeed or fail, more so than any methodology or technology.

Do you have a burning question about Git, GitHub, or open source software development? Drop your question to us on your social channel of choice using #askRMP, and it may be answered by a panel of experts in an upcoming newsletter or a future episode of The ReadME Podcast!

Want to get The ReadME Project right in your inbox? Sign up for our newsletter to receive new stories, best practices and opinions developed for The ReadME Project, as well as great listens and reads from around the community.

Written by

Mike Melanson

@mikethemelanson