How to develop good malware (and software in general)

I'm going to preface this article with stating what is obvious by anyone who has watched my videos or livestreams on YouTube: I'm not a good malware developer. I'm trying, and I've gotten better, but anyone who has watched my  content or read my blogs on the subject knows it's not my strong suit.

That said, I am a good learner and that's what this blog is about. Let's talk about how to get good at software development more generally.

I'm going to use the term software developer/development for the rest of the article because, spoiler alert, the advice I'm going to give here is just as applicable to web app development as it is to software development.

What does it mean to be a good software developer?

Yes, we've all seen the meme:

Even Senior Developers rip their code from StackOverflow

It's true. Every software developer I meet relies on Google as their memory bank. You don't necessarily rip code, but you do use snippets found online pretty heavily. Anyone who says they don't is a graybeard god, a savant, or lying. The former 2 types are exceedingly rare, especially in online debates over what makes a good software developer.

What separates a junior or mid-level software developer from a senior or staff-level is complicated. So complicated that hiring managers across the industry are left scratching their head at the subject. Someone with ten years of experience on paper might write "worse" code than someone with a couple of hard-fought years and some bootcamps.

That said, experience usually leads to an increase in proficiency: an experienced developer usually writes "better" code, faster and more efficiently, and can explain what they've written more thoughtfully. Is it just experience, then?

I don't think so.

To me, what you gain with experience is an understanding of systems and how to design them. You may not know that command to run through the AWS console to get what you want, you may not have a wealth of complex SQL query knowledge memorized by heart and you might not be able to recite the docs for your library of choice, backwards and in latin... but you know how the system needs to be designed. What pieces need to be built, how the pieces talk to each other and what requirements are needed.

You'll also know a bit more about all of those pieces. I can't tell you how every single React hook works (especially with how frequently React is changing) but I can tell you, for example, how to organize a React project efficiently. I can't give you a rundown of why FastAPI is better than Flask, but I can show you my benchmarks and explain how to build a FastAPI backend pretty quickly. Some of this comes from raw experience, but a lot of it comes from pure curiosity that leads to poking around and learning more.

What you end up with is a developer with a wide breadth and varying depth of knowledge of a lot of the pieces that go into their preferred stacks, with some variation. You get someone who can design a system quickly, develop it fairly quickly and explain to a stakeholder why they did it the way they did.

Does a good developer have encyclopedic knowledge about some things? Yes, especially with more seniority. As you gain experience, you're naturally going to lean more heavily on certain stacks and languages over others, which means you're going to get really in the weeds in those subject areas.

However, there's a long and hard road to reach the level of graybeard genius savant... a road I am just beginning, even as a staff software engineer.

The road to the Graybeard Savant

How does one get to be a good software developer, now that we understand what that looks like? In my view, there isn't just one road... there are many. Most of those roads, though, share a couple of common junctions that can really help you out. Let's talk about those commonalities.

Write more software

This is probably glaringly obvious. To become a good developer, one has to write more software. I don't like speaking in absolutes, but this is an absolute truism: you do not become an expert guitar player by reading every book on theory and watching hours of Steve Vai or Tim Henson playing guitar. You have to pick up the guitar.

I've linked to the video many times in my livestreams on YouTube, but I'm going to do it again:

Watch this video by the brilliant Theo and really let the lesson sink in. Watch tutorials just long enough to get the gist, then build something yourself.

Not only does this develop your pure technical chops, but it also flexes some of your creativity, too. You learn to think about how systems are designed, and how they can be designed better. You begin to think about ideas for apps to build and websites to deploy. You begin to see things that can be done better and start to think about how you can make them better.

Software development has some significant muscle memory involved. As you code, you start to develop habits, systems and methods of designing systems and components of systems. This will make you a better developer.

Do I have a "lines of code per day" figure in my head? No, that's just as silly as measuring developers' efficacy with lines of code committed. Should you code every day? Maybe. I probably sit down in front of an IDE 5-6 days out of a given week. Should you burn yourself out in the ever-distant goal of becoming a Wizard? Absolutely not. Go touch grass.

Write better software

This... sounds silly and obvious. Let me explain.

If something is wrong with a piece of code you or someone else wrote, go fix it. Don't just say "okay LGTM let's push to prod" without trying to make it better first. What you'll find is that either the way you or someone else wrote the code is the way it is because the developer didn't think about a better way, a better way didn't exist at the time of writing, or there are constraints present that you didn't know about.

If the developer didn't think of a better way, or the better way didn't exist at the time, you get to improve some software, whether it's open source or an internal project at work. If there are constraints present that you didn't know about that dictated the software be written that way, you get to learn a ton about those constraints, which is an incredible way to grow as a developer.

There is another 10,000 word article to be written (and probably plenty that have been written) about the attitude of "it works, ship it" leading to decaying software quality, but what it also creates is decaying developer quality. Developers can decay, or at least be kept from reaching their full potential, by settling for "it works" over the much loftier goal of "it works as well as it possibly can." Don't let your skillset lay in disrepair: write good code.

Dive into docs... and other people's code

I've found myself returning to the documentation for libraries and stacks I've used for years to really understand how those libraries work recently. The most common method of reading docs is to find the solution to a specific problem: what's that method name, what are its inputs, how do I format this or that data-type, etc.

Instead, dive into the docs. Understand how classes are laid out and what lesser-used functions those classes contain. You'll find in many cases that libraries you thought you knew inside and out were, in reality, singificantly more complex, or at least more deep, than you thought... and you'll be so shocked you will go back to re-write some of your projects.

Go back and read the Flask docs. Go back and read the basics of how C data types work. Go back and really understand Next versus React (this is the one I'm working on now, unfortunately...) and what advantages and disadvantages each has. You don't have to spend hours memorizing, but you should really dive deep to get how things work... because those libraries and classes are the foundation of the systems you'll be building.

Ditto for other people's code. I can't tell you how many times I Google'ed "site:github.com example app for <insert library/framework here>" and read over someone's code to get a feel for how a library/framework works. It may not give you the end-all solution, and their code may be flawed, but you can at least accelerate your own learning by understanding a pre-existing implementation.

This, frankly, is an area I'm actively trying to improve upon. I want to contribute more to open source code, and that means reading enough code to understand how to improve it. I think this is a hidden gem of advice, and can really accelerate your learning.

Dive DEEP out of your comfort zone

When I ask you "what is your favorite stack?" what would you say?

Now, go through each part of that stack and think of a possible alternative. Like Flask or FastAPI? Think ExpressJS. Like React? Think angular. Like Tailwind? Think Bootstrap, or raw CSS. Like C? Think Rust. Like Java?

... why?

This is something I'm actively working on. I've now built backends in Flask, FastAPI and ExpressJS, three frameworks across two languages. I cannot tell you how helpful this has been to understanding backend development. Pick one of those alternatives that you're interested in and really learn it, don't just write a Hello World program in it, go rewrite one of your projects with it. Have some malware you wrote up ages ago? Rewrite it in Rust. Have a frontend that you used Tailwind for? Rewrite it using Bootstrap.

You might end up hating the alternative... or you might build out a new main stack. You won't know, and you won't get a feel for each framework's advatages and disadvantages, until you try.

One of the more important practical parts of this advice is that you may find yourself in a new job that uses the alternative over your preference. All of a sudden, you'll be forced to learn that alternative... because your job isn't going to pay you 6 figures to rewrite everything. Trust me.

Interface with other developers

This is something I'm just now getting to work on, because as I noted, I've only recently transitioned into pure software development. Now I spend every day speaking with developers way better than me about what they've written and what I'm writing.

This basically 10x's your potential because you build a brain-trust of intelligent, experienced developers you can bounce ideas off of, work on solutions with and ask questions. I'm not talking about Twitter DM's or Reddit threads, get in some real conversations with developers, read pull requests, listen to talks and really interface with that community.

Very few professionals will tell you it's a bad thing to build a professional network full of smart people.

This isn't a finished guide

This is not a bible for developers. It's not a finished guide. Hell, there are parts that might be outright wrong. I don't think so, but I'll admit it if someone points it out.

Becoming a good developer is hard not just because of the steps required, but because the definition of a good developer is an incredibly fuzzy goalpost. It's hard to define who is good and who isn't and, because the goal is so unknown, it's difficult to define a roadmap.

Let this article serve moreso as a guide to get close to the target and to improve significantly in a more or less efficient way. I'll be publishing updates when new ideas cross my mind, so keep your eyes on this blog (and, plug alert, subscribe to my Ghost blog) to get updates when I do.