Forem: Marek Zaluski

Writing Readable Code: Why It Matters and How to Do It

Marek Zaluski — Wed, 15 Feb 2023 14:23:26 +0000

There's a joke in programming that some code is write-only. It's a reference to the fact that code can be impossible to read, and that the only moment when it can be understood is at the moment of writing.

The reality is that code readability is a big deal with significant consequences.

There are many competing priorities when developing software, and readability can sometimes become a second thought. It's easier to make the case that code should be fast, bug-free, and shipped quickly. But I'm making the case that readability can be a number one priority, too. In fact, it can you help achieve all of the other priorities: it makes it easier to write faster code, it makes bugs more discoverable, and it allows you to ship faster.

Who is it for?

When you're putting effort into making code readable, who are you doing it for?

In some cases, the person who will be reading it is your future self. You might have all the context about the code in your mind right now, and you might think you're going to understand it in the future. But the reality is that we forget quickly.

Making your code readable is a gift to your future self. It's a gift of time and convenience because it will help you get back into the code faster and spend less time trying to figure out what's going on.

Aside from being a gift to your future self, it's also a gift to anyone else who will be reading your code. This includes your co-workers and collaborators who will be reviewing your code in the immediate future. But it also includes people who you don't currently know: future collaborators, or people who will be maintaining your code long after you might be gone from your position or role.

Sometimes you're on a team and you can ask co-workers to explain the code that they wrote. But there are many times when that's not the case: the original authors of the code might be unavailable or they might have left the company or the project long ago. I've had situations where I've wanted to ask the code author for an explanation of what they wrote, only to find out that they're no longer at the company.

Writing readable code is also a gift to those who are learning. What best practices of readability do you want to pass down to future developers? It's a great opportunity: instead of gatekeeping our knowledge, we can make it easier for newcomers into the profession to read and learn.

How to write readable code?

Put yourself into the shoes of someone who is reading the code for the first time and doesn't have a lot of context about how it works. What do they care about?

First, make the intent clear: what is the code intending to do?

The two main tools you have at your disposal for clear intent are descriptive names and intentful comments.

Descriptive names apply to function names and variable names in particular. Here, the idea is to stuff more information about what a function is intended to do into the name itself. Variable names can also have a lot of meaning stuffed into their name: what data they contain, and what that data is for.

The best descriptive names are consistent in their level of detail. And they can evolve. In a simple project, you can survive with short names that don't need to specify a lot of detail. But once the number of functions and variables gets large, then you really start to benefit from longer and more descriptive names. That's because, with growing complexity, there's more to be said about how each name is different from the others.

The second tool is writing intentful comments. This is what I call comments that carry intent. They describe not just what a piece of code is doing, but what it's intending to do. This might mean answering the "why" behind the code. A good "why" explanation doesn't just explain the reasons behind the way that the code was written, but it also mentions the alternative implementations that were considered but were not used.

Intentful comments can be the most useful help when debugging: if you're trying to figure out a bug and you see a discrepancy between how the code functions and how its intent is described, this can be very valuable information for narrowing down the location of the bug.

Writing readable code makes you a better programmer

In conclusion, it's worth making readable code a priority. It pays off in the future, making it easier for you to come back to your old code and quickly get right back into it, and also making it easier for collaborators to work on it.

Writing readable code makes you practice empathy as a programmer. It forces you to think about the state of mind of someone who will be reading the code without all the context and understanding that you have in the moment. And that's a great exercise to make you a better developer.

Are Callbacks Always Asynchronous?

Marek Zaluski — Tue, 18 Feb 2020 12:54:08 +0000

When I was learning JavaScript and first encountered the concept of callback functions, I was still trying to wrap my head around the whole "asynchronous" idea.

Because callback functions seemed to get involved every time something asynchronous was mentioned, I had the understanding that if you were talking about callback functions, then it meant that you were doing something asynchronous.

In fact, I've seen a lot of tutorials and courses that tell you that a callback function is a type of asynchronous function.

Well, this is actually not true.

It turns out that callbacks aren't necessarily asynchronous at all.

But in order for that to make sense, it's helpful to have a clearer definition of what a callback function actually is, and also a clearer definition of what "asynchronous" means.

What's the definition of a callback function?

You're in the presence of a callback when you can see this situation in your code:

A function is being called. (Let's name it function Alpha).
Some other function is being passed as an argument into that call. (Let's name it function Bravo).
There's an expectation that Alpha is taking on the responsibility of calling Bravo, at some point in time.

The shape of the code looks like this (which is the syntax of a function call with one argument):

alpha(bravo);

If the situation matches the those three conditions, then Bravo is a callback function. It's being passed into a function call as an argument with the expectation that it will get called. That's a callback.

Let's take a look at an event handler example and we'll confirm that the above points are there.

If you're waiting for a mouse click on your page, you might use the addEventListener method. If you're using a framework like React, then the onClick prop works in almost the same way.

function doSomethingAfterClick() {
  numberOfClicks++; // Count the number of mouse clicks, just for the sake of example.
}

const button = document.getElementById('action-button');

button.addEventListener("click", doSomethingAfterClick); // here is the callback situation

In this example, do we have...

...a function being called?
- Yes, we're calling addEventListener, our Alpha function.
...a function being passed as an argument into the call?
- Yes, we're passing doSomethingAfterClick, our Bravo function.
...the expectation that Alpha will call Bravo at some point?
- Yes, when a mouse click happens, we expect that doSomethingAfterClick will be called.

So we can conclude that yes, it's a callback function.

To clarify the 3rd point of the definition, it's helpful to ask: who is calling the callback function?

In our example, who is calling doSomethingAfterClick? It's not our own code, because we don't see doSomethingAfterClick being called. If we were calling it, then we would see the function call syntax which includes the brackets after the function name: doSomethingAfterClick(). We don't have that here.

So, we can conclude that addEventListener is the one who will be responsible for calling doSomethingAfterClick. Because even if we don't see the explicit function call, we know that addEventListener can take our callback and can do whatever it wants with it, which includes making sure that it gets called when that click event happens.

Callbacks can be synchronous or asynchronous

After talking about the definition of a callback function, we can see that callbacks don't have anything to do with the async concept at all. They're just regular functions, and they don't know or care whether they're going to be called asynchronously or not.

But what's the difference between a synchronous callback and an asynchronous callback? What does it even mean when we say that a callback is asynchronous?

How to tell if it's an asynchronous callback?

Instead of going deep under the hood to find a technical definition of what asynchronous code means, I think it would be more helpful to stay close to the surface and ask: what can we actually observe that's different between sync and async callbacks?

To figure it out, we need to know what happens and in what order. Let's write a timeline based on the above scenario with functions Alpha and Bravo.

We call function Alpha and pass Bravo, our callback, as an argument (example: we call addEventListener)
Alpha returns. (this happens right away).
Bravo, our callback, gets called. (example: a mouse click event happens)

The important thing to notice is the order of #2 and #3. First, Alpha returns. Then, Bravo is called at some later time.

This tells us that it's an asynchronous function. The reason is that the only way for Alpha to return before Bravo is if it puts Bravo into the asynchronous queue, causing it to be called at a later point in time.

I like to use the term parent function to refer to Alpha. The parent function receives the callback and takes responsibility for calling the callback.

Here's how the relationship between the callback and the parent function looks on the timeline:

On the other hand, if we had a synchronous situation, then it would mean that Alpha is calling Bravo directly and therefore needs to wait until Bravo returns before it can return too.

How to tell that it's a synchronous callback?

How would that timeline look if we had a synchronous situation?

We call function Alpha and pass Bravo as an argument
Bravo, our callback, gets called.
Alpha returns.

So the relationship between the parent function Alpha and the callback function Bravo now looks like this:

Here are some great examples of synchronous callbacks:

the forEach array method. forEach takes a callback and it calls that callback once for every item in the array, waiting for each call to return before forEach itself returns, meaning it's synchronous.
the map array method. It also takes a callback and calls it for every item in the array. And because it has to wait for each call's result before it can produce the final output array, it doesn't even have a choice but to be synchronous.
filter and reduce also work in the same synchronous way.

If we were to draw these examples, we'd actually draw the blue box being called multiple times, and those calls would all happen before the parent function returns.

You can also look at the code of a function to figure out if it uses sync or async callbacks. If you can see the callback being called directly, with the function call syntax (like callback()) then you know it's synchronous.

Here's a function that uses a callback synchronously, and we can know this with certainty because we can see that the callback gets called directly:

// Example of a sync callback
function callWithRandom(input, callback) {
  const output = Math.random() * input;
  callback(output); // the callback is being called directly, right here
}

This matches what we see on the diagram, because the call to callback(output) must be completed before the JavaScript engine can reach the end of the parent function and return from it.

Conclusion

What's the relevant part of this story? Let's recap the main points.

A callback function is a function that gets passed as an argument into a parent function call.
There's an expectation that the callback can be called by the parent function.
A callback can be used synchronously or asynchronously.
There's a difference in the order in which things happen in the timeline, depending on whether the callback is used synchronously or asynchronously.

My next articles will cover more topics on the fundamentals of JavaScript execution, so click Follow to get notified about them.

Soft Skills Are Out. Here's a Better Model

Marek Zaluski — Mon, 17 Jun 2019 16:12:25 +0000

I started out my developer career focused on the kinds of skills that I thought were most important: the technical skills.

Consider the question: what makes a good developer good?

The most common answer: it's the level of their technical skills.

As I got more experienced and as I worked with more teams (and larger teams), I started to realize that it isn't so simple: there's more to the story.

The most effective developers that I met weren't just skilled in technical ways. They were really good at a few other key things too: explaining problems clearly, sharing solutions with team members, and being good at communication in general.

So I took a look at my own skill-set and I saw that yes, I was making a lot of progress on the technical side and I was learning a lot of new tech skills. But I wasn't really doing anything to improve my communication skills.

There's a term that's often used to refer to these non-technical skills that are nevertheless important for a job: soft skills. These are usually defined as some combination of communication skills, teamwork skills, and empathy.

Some definitions of soft skills might also throw in things like professionalism, accountability, or integrity.

Getting good at soft skills, just like technical skills, requires deliberate practice.

I realized that I needed to get better at communication so I started practicing. I started a writing habit, published some blog posts, and generally tried to see where I could improve how I work with my team members.

And outside of working in a team, when I eventually started doing solo consulting work for clients, I realized that there's a whole set of communication skills that are important in that kind of work, too. Communication can make or break your relationships with clients.

Soft skills: the wrong label?

// Detect dark theme var iframe = document.getElementById('tweet-1139157303293337601-537'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1139157303293337601&theme=dark" }

I recently came across the idea that the phrase "soft skills" isn't actually the best term. I've been using the phrase for a long time but now I agree: calling these skills "soft skills" leaves out a lot of nuance and it implies some assumptions that aren't true.

Problem 1: "Soft skills" sounds less important than "tech skills".

Reality: Soft skills are just as important, if not more important, for career success.

If you look at it from the perspective of a particular job, or a particular task, then sure: in those cases you can probably identify specific technical skills that are needed to succeed.

After all, if you're working on something technical like an operating system kernel, then knowing the inner workings of the kernel is a pre-requisite skill. There's no way around that, and being really good at communication isn't going to help you directly.

But if you zoom out and look at the bigger picture, and consider a longer time span like your entire career, then communication and teamwork skills start to really show their importance. If you want to progress in your career and face new challenges, then these are the skills that are going to be just as important or more important than the tech skills.

Problem 2: "Soft skills" can imply that these skills are easier than "hard skills"

There's an argument to be made that by calling them "soft skills," you're making these skills sound like they're easy and therefore make them seem less valuable.

There's no doubt that technical skills are difficult to learn. There's a lot of work, effort and practice involved.

But so-called soft skills are difficult in different ways.

First, it's difficult to self-assess how good you are at communication without taking the time to reflect and introspect. There's no test or metric that can tell you how good you are at it. You have to make a deliberate effort to look for ways to improve.

Second, communication and teamwork require empathy, and that's not an easy skill to acquire. You can't learn it from a book, a course, or a tutorial.

Third, you have to learn to listen. When you hear about "communication" as a skill, it's easy to think about only one side of it: transmitting information to others. But that's only half: and the other half, arguably, is even more important. It's listening and understanding what other people are saying. In my experience, that can be a blind spot for many people, even those who think of themselves as good communicators.

So what can we call them instead?

Instead of calling them "soft skills," we can call these skills something that's more accurate, something that reflects a better career mindset.

// Detect dark theme var iframe = document.getElementById('tweet-1138458240281382916-411'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1138458240281382916&theme=dark" }

There are some ideas floating around for an alternative name for these skills, but my favorite is "core skills."

Why core skills? Because they're at the core. They're at the middle of your skill-set and career, not on the outskirts. And all of your other skills (including the technical and specialized ones) connect into them directly.

Every single one of your other skills is amplified and made more powerful when it connects to a strong core.

So if you were to make a diagram of your skills as a professional, it might look like this:

Core skills are a better model for thinking about soft skills

If you do some research on the term "core skills" then you might find that some people have already used the term to refer to technical skills. It may also have some overlap with the use of the phrase "core competency."

But that usage aside, I really like the visual of placing these skills at the center, and giving them the attention that they deserve. It's where they should be.

Ultimately, the question that you have to ask if you want to maximize your career success is "where should I be investing time and effort into my career?".

And the message should be: invest in technical skills that help you specialize, but no matter what your specialization is, make sure to invest into making your core as strong as possible.

PS. I'm starting a newsletter and channel for developers called Developer Mission. If you want more of my content about how to find clarity in your software career, sign up at developermission.com

Should You Throw Away More Code than You Keep?

Marek Zaluski — Mon, 22 Apr 2019 18:43:16 +0000

Once in a while, I like to pick a random NPM package that I'm using in my projects, and go read the source code on GitHub.

When I was first learning JavaScript, I read some of the source code for jQuery and Express. It was a positive experience. I was surprised that I could understand a lot more of the code than I expected. There were definitely a lot of terms and concepts that I had to look up as I went along, but that helped me learn a lot of new things.

I expected it to be much more intimidating, it was actually very readable. That's probably in large part because I was lucky that jQuery and Express are well-written and documented projects.

I've also read some really messy codebases (and written a lot of messy code myself), and it showed me that there's a lot of variability in the software world. No two projects as alike.

But here's what reading source code doesn't show you:

You don't see what paths development took and how the code got to where it is today. (unless you go digging through git commits, which I recommend as well).

When you read the source code of a fully-formed, well-maintained and well-documented project, you might get the impression that the developers really knew what they were doing. When you look at the finished product, it might seem like the authors had everything figured out, and they just sat down and wrote it.

The reality is: they probably threw away more code than they wrote, before arriving at the current state.

In fact the code probably went through a lot more iterations that it might seem.

So when you're learning and working on your own projets, don't be afraid to throw away code.

Code is free to write, so write lots of it. Code is also free to delete, so delete at will.

As long as you keep producing, you'll keep getting better at it.

By having the mindset that it's okay to throw away your code, you're going to write more and that's how you improve.

Do you agree? Should you throw away code more code than you keep?

Why You Need (at least) Two Mentors

Marek Zaluski — Fri, 05 Apr 2019 14:36:27 +0000

Here's one of the best pieces of career advice: Get a mentor!

The support and feedback that you get from a mentor is invaluable. You don't get this kind of value from any other source of career input: whether you read career blog posts, watch Youtube videos or follow people on Twitter, nothing is as useful as a mentor who you can actually talk to.

But when people say "mentor", they aren't always talking about the same thing.

There are two kinds of mentors. Let's break it down.

The job mentor

If your mentor is one of your co-workers, then they're what I call a job mentor.

At some companies, when you join the team, they assign you to a mentor. That mentor's task is to get you acquainted with how things work at the company, and serve as someone that you can turn to with questions and concerns.

If there's no official mentorship program at your workplace, then you should try to get a job mentor by approaching someone yourself. It's good to do this early on.

Ideally, find a mentor who is not your direct boss. This is because the mentor relationship is different than the boss-subordinate relationship. The mentor is the person you can go to when the concern or question that you have is actually about your relationship with your boss.

The career mentor

If you have a mentor outside of your workplace, then you have a different kind of mentor: a career mentor.

A career mentor is someone you can talk to when you're looking for big-picture career advice. It's someone you can ask about switching jobs and deciding on your next move.

Having a career mentor is good for the questions that you wouldn't ask your job mentor. Maybe you have serious concerns about your workplace and you want an outside opinion. Maybe your employer isn't investing into your career development because they don't want you to go get a better job elsewhere. Then you need an external perspective.

Let's be real for a minute. Not all employers care about your career development. Most just care about the here and now: the productivity that you're providing to the company's bottom line at the present moment. So your employer isn't typically the best place to get good career advice for the longer term.

How do you find a career mentor? Approach someone who is a few years ahead of you in their career, and who is doing the kind of work that you'd like to be doing. Ask them about their career path and how they got where they are. Most people are very eager to share their work experiences.

You need both

Ideally, you need at least one mentor of each kind.

You need someone to "on the inside" in your company so that you can decode the company culture and figure out the unwritten "this is how we do things here" rules.

But you also need an outside perspective who can call out the group-think of your workplace.

Do you have a story of how a mentor helped you in your career? Share it in the comments.

Think of Your Career as a Series of Stepping Stones

Marek Zaluski — Thu, 21 Mar 2019 21:00:30 +0000

If you want a fast-moving career, think of each job as a stepping stone. A good stepping stone is one that gets you closer to the next stone in your path, towards your end-goal.

The end-goal is your dream job or ideal career.

The thing about stepping stones is that you have to make a jump if you want to reach the next one. You can stand on a stone as long as you want but it's not going to move on its own.

A slow and steady career, on the other hand, is more like floating downstream in a slow steady river. You're not going to go as fast, but you don't need to do as much jumping. And you don't have as much say about where you're going to end up.

Choosing to make the jump

Years ago I was at a crossroads in my career where I had a job offer to work in PHP and another offer at a different company to work on JavaScript and Node.js.

I was much more comfortable in PHP. My knowledge of JavaScript had a lot of holes in it and I didn't know much about Node.js except for what I had learned in a few hackathon projects.

I would have been in my comfort zone with PHP. I wasn't looking for comfort, though. I was looking to keep my career moving and jump to the next stepping stone.

Jumping into the deep end

So I took the JavaScript job. I have to be honest, it was a lot of work to get up to speed. I had to learn how Node.js does things, which was very different from PHP -- and also different from Rails and Django which I had used before.

But I knew that JS is where I wanted to take my career next. I wanted to go after where I saw the action. The opportunities were there and when I looked at Node.js, which was relatively new, I saw a platform that was picking up steam at breakneck speed.

I could have worked on my JS skills in my free time while working in a comfortable, slow-moving day job. I could have played with Node.js in my personal projects, while writing code in PHP at work.

But I didn't have the patience, nor the extra time and energy for that.

That's why when this opportunity came knocking, I'm glad I recognized it. It was an employer who was willing to take a risk on me and my skills, and who basically wanted to pay me to learn things.

Choose your next job strategically

Not all employers will give you this kind of opportunity. In fact, the majority of employers are not willing to take risks, and many of them are bad at hiring overall. To be fair, hiring well is a really hard process.

How to maximize the chance of finding good stepping stone job opportunities?

Decide if you want to take some risks and if you want a fast-moving career. If you're at a point where you want stability, then a stepping stone strategy might not be the best choice.
Know what you want to learn next. Look at where the action is in the industry, and see where you can build career capital.
Recognize the effects of hype in the tech world and how you can take advantage of it. What you want is not short-term hype, but medium-term: the cycle needs to be long enough for it to be a worthwhile career capital investment.
Show that you're willing and able to learn fast. Smart employers know that this is more valuable than X number of years of experience in a technology.

Pick the job that matches your philosophy

It was no coincidence that the employer that was looking to hire someone to do Node.js was also willing to hire someone based on eagerness to learn instead of years of experience.

This was a time several years ago when Node.js was in its early stages. And this company was an early adopter. Their very philosophy was to move fast, learn fast, and take advantage of new technology. So they were looking for people that shared that philosophy.

If you want a stable, slow-moving career, then pick a slow-moving technology stack. Stability can be a good thing if that's what you're looking for.

You can stay with PHP or enterprise stacks like Java or .NET for a solid, stable career: but generally speaking (and ignoring the expections) don't expect to find fast-moving, risk-taking employers in those stacks.

Learning something from each step

I learned a lot from the work that I did with PHP: it made me a better programmer.

I also had a few stepping stones that involved Python, Ruby, Go and some other stacks.

In retrospect those steps were a bit to the side, rather than aligned straight-on towards my goals. Only later did I decide to go all-in with JavaScript as my chosen language of expertise, and I didn't pursue those other languages further.

You don't always have enough visibility to tell which step you should be taking, or which direction you should be going.

As long as you're not stepping backwards, then you're going to learn something new with each and every jump. And you're going to see your next steps more clearly.

Why Programming Languages Are Hard

Marek Zaluski — Mon, 04 Mar 2019 18:23:16 +0000

Years ago when I first tried learning Python, within the first five minutes of playing around with it I encountered one of these error messages:

SyntaxError: invalid syntax

It sounded like Python was telling me: you did something bad, and you should feel bad.

I did feel bad, in part because I had no idea what a SyntaxError meant, and the phrase "invalid syntax" didn't help clarify anything at all.

Today, I know a lot more about programming languages and about how parsers work. But the error message is still bad. It's bad UX, or more precisely: bad DX (developer experience).

If you're learning programming for the first time, then the error is a bad experience on two levels:

First, it doesn't tell you what just happened. Did I do something wrong? Did my program do something wrong? Or did Python do something wrong?
Second, it offers no indication of what the reason for the error might be, or what I could try to do to fix it.

Now, the reality is that syntax errors happen all the time (even after years of experience) and that most of a developer's life is spent fixing bugs and troubleshooting all kinds of coding problems.

But as a beginner, you don't know that.

When you're a beginner, this error actually sounds like it's a big deal, and more critically, it sounds like you did something wrong.

The problem: programming languages are created by programmers

Programming languages are created by programmers, for programmers.

That's a problem when you want to make programming more accessible and easier to learn. It's a target audience mismatch.

On top of that, there are limitations that come from how programming languages are created. We end up with messages like "invalid syntax" not just because someone wrote the error message like that, but because of the way that the language grammar and parser work. Maybe the parser actually doesn't have access to the exact grammar rule that caused the syntax error, because it was coded that way. So the error message isn't capable of being more helpful for technical reasons.

It's very likely that it just wasn't one of the priorities for Guido when he was writing the first version of the Python parser. He was writing it for himself and for other programmers.

After all, when Python was first released in the early 1990s, it was already much simpler and easier to learn than most other languages at the time. (I think that might still be true today.)

A secondary problem: programming languages which are designed to be easy to learn tend to be useless

There are lots of programming languages that are designed to be easier to learn and to be accessible to beginners. Very few of them are successful or popular, and the problem is that you can't do any serious work with them.

They may achieve their goal of making it easier for people to get started with programming. But a lot of the time they fail to illustrate what problems programming can solve, and how it fits into a bigger picture.

So in a way, they actually sabotage themselves before they can fulfill their goal.

If you want to show people why programming is worthwhile and help them understand how they can use it, you need to show them how to solve a real-world problem. Otherwise, most of the time, it ends up looking like a toy.

HyperCard and Excel

HyperCard was one of those applications that emerged in the late 1980s that had an influence on a huge number of computer users and I would bet that it inspired a lot of people to become programmers.

The programming language that was available inside of HyperCard, called HyperTalk, wasn't particularly great. But it was aimed at non-programmers while at the same time being capable enough to solve real problems.

Many people who thought they would never be able to program a computer started using HyperCard for many automation and prototyping tasks, a surprise even to its creator. (Wikipedia)

Excel is the other application that was huge in bringing programming to non-programmers.

Based just on formulas and cells, Excel's model managed to be half-code and half-graphical. It's generic enough to solve a whole range of problems, but it still sticks to a sweet spot: it's specific to problems that can be expressed as a spreadsheet. That's what keeps Excel so powerful: it doesn't try to do everything. It's a spreadsheet.

Making a tool customizable until it becomes a poorly designed programming language

In software, we're always faced with a trade-off between writing code that solves a specific solution, and writing code that allows the user enough customizability to solve a wide variety of problems.

It's the tool specificity problem.

Excel and HyperCard are tools, not programming languages. But both of them were pulled in the direction away from specificity, to try to solve all problems for everyone.

What's the most customizable form of a piece of software? It's a programming language itself. So if you take those tools to an extreme point of customizability, they become poorly designed programming languages.

Why is HyperCard dead today? I think it's because it was too generic and wasn't a perfect fit for any specific problem.

While it did put a lot of power into the hands of non-programmers, eventually it turned out that the economics of software is such that it's usually more worthwhile to have specific tools built for specific problems.

Programmers solve their own problems

It's normal to expect that if you leave programmers to their own devices, they're going to make tools to make their own work easier.

Sometimes programmers are guilty of a certain kind of elitism, where they put up barriers to entry instead of making things easier for newcomers.

Once you get past the initial hurdles and you learn how to write code, you start to forget what it felt like when you were just getting started.

It's remarkably easy to forget how helpless you felt when you were trying to learn the basic syntax of your first programming language and everything seemed stacked against you.

Everyone starts out as a beginner.

So, what can we do to make things better?

Rants aside, here are some actionable suggestions.

If you're an experienced coder, share stories about your first encounters with programming to show that we all start out clueless and intimidated before we got the hang of it.
If you're a beginner, try to forgive the creators of programming languages for the cryptic and unhelpful error messages. Creating a programming language is a lot of work, and it's not always obvious how to make it easy for beginners while also making it useful for solving real problems.
Also if you're a beginner, you can help the programming language community by sharing your experiences and your feedback. A lot of the time, the experienced programmers need a reminder that beginners don't see things the same way that they do, and they need to snap back to reality sometimes.
Forgive the beginner-friendly programming languages if you can't make anything useful with them. They can still be worthwhile learning tools, and if they can get people excited to learn more about programming in general, then that's the best we can hope for.

Let me close with one last thing.

I was too harsh above when I called those languages useless, but I meant it in relation to real-world, so-called "business" problems.

If you can use a tool to make cool or creative things and then show those things off, then that tool is 100% useful and valuable to humanity. Let's make more of those.

Three Arguments for Why You Should Write More

Marek Zaluski — Mon, 28 Jan 2019 18:08:15 +0000

Let me try to convince you to write more.

I don't mean write more code. I mean write for humans.

There's a huge benefit to getting good at writing as a developer. And all it takes it practice.

You don't have to be a good writer to write. In fact, it's the opposite: you have to write a lot first, and then with time it becomes easier and easier.

Being good at writing isn't about writing high-quality stuff at all. Quality doesn't matter. You can have a crappy blog post and that's infintely better than no blog post at all.

The goal of practicing writing is not to write high-quality material. The goal is to get efficient and fast at getting your thoughts into text. It's a skill that's for you first, and for the reader second.

The more you write, the easier it will feel to just open up a blank page and write.

You might tell me: I'm not a writer, I'm a developer. I don't have time for writing. Well, then this post is for you. Let's jump into 3 arguments for why you should do it.

An argument for the collaborators

Writing is the most powerful way to boost your value as a collaborator.

Most software teams aren't bottlenecked by how much code they're writing. They're bottlenecked by the bandwidth of the communication between team members.

Here's a good strategy for any team of developers: over-communicate. You can't go wrong with over-communication, because you will eliminate a LOT of problems due to misunderstandings or miscommunications.

Here are important things that you can do that involve writing:

Share progress reports with the rest of your team
Write tutorials and onboarding checklists to help new team members get up to speed
Describe obstacles that you encountered and how your team solved them
Make bug reports better by writing about the fixes, the trade-offs and the lessons learned

If some of your team members are remote, or if sometimes people on your team work from home, then written over-communication becomes critical.

If you're having in-person conversations at the office and things don't get written down, then the team members who are absent are going to miss out on important information.

Slack messages are OK for short-term ephemeral communication. But if you want your team to get serious about collaboration, write things down for real. I mean outside of Slack: in a knowledge base, a wiki, or a documentation repo. Somewhere where you have to lay out your thoughts in a structured way.

An argument for the competitors

Maybe collaboration doesn't get you motivated.

Maybe you're competitive and you're more focused on career advancement right now.

Getting good at writing as a developer is a remarkable way to stand out from the crowd.

Communication is a skill that's overlooked a lot by developers. From the many conversations that I've had about this, I suspect that a lot of developers get into this line of work precisely because they'd rather interact with computers than with people. If you're competitive and you want to get ahead in the career game, then writing can be a huge advantage.

Start a blog. Write about your projects. Share what you're learning with the world. These are powerful tactics for career advancement. This is how you get noticed and how you get your foot in the door at your dream company.

An argument for the introverts.

I call this argument "for the introverts" for lack of a better term, but that's not exactly what I mean.

Here's what I actually mean. If the above two arguments don't do it for you, then just write for yourself.

A large part of software development is problem solving. And problem solving starts with identifying and verbalizing what kind of problem you're looking at in the first place.

Describe the problem. Write it out. It'll force you to really think about what you already know, what you need to find out, and how to put the pieces together.

It's amazing how much simpler most problems start to look once you write them out. Sometimes you figure out a solution before you're even done writing the problem down.

It's like the concept of rubber duck debugging. It's helpful to talk through a problem with someone, because the act of talking helps your brain map out what's going on and it gets you closer to a solution.

Writing is even better than talking to a rubber duck. It gives you a record of the problem that you can return to in the future. And you can share it with others who are facing a similar problem. That's a huge win right there.

It doesn't actually matter what you write

I tried to lay out 3 perspectives on writing, to appeal to different motivations that might speak to you.

Here's something that I've learned: if you want to get good at writing, it doesn't actually matter what you write. Just write.

The practice adds up. And let me reiterate: don't worry too much about the quality of your writing. That kind of worry is what causes writer's block. I like Seth Godin's advice on this. He says: write like you talk. Nobody ever gets talker's block.

Don't know what to write about? Pick things from your own daily experience. Write about what you learned today.

Don't have anywhere to post it? Post it on dev.to.

If you do this every day or every week, I guarantee that your writing ability will improve fast. It's all about quantity and consistency.

You Learn Faster in Messy Workplaces

Marek Zaluski — Mon, 21 Jan 2019 16:20:47 +0000

I've had the pleasure as a developer of working with some amazing teams on some beautiful projects. Their onboarding process was good, the documentation was complete, there was a full suite of automated tests, continuous integration and code reviews.

Those kinds of projects are a joy.

But that's not what this post is about.

I've worked on some difficult projects that were the complete opposite. No testing, no automation, documentation that hadn't been updated in 6 months, and nobody knew what changes were being made because there were no pull requests or code reviews.

There's usually a combination of typical reasons for this state of affairs. Often it was pressure from management or unrealistic changes in scope happening at the last minute. Some teams tried to use a Scrum process and succeeded in doing sprints and daily standup meetings but it didn't make things better.

The root problem wasn't just the lack of a process, it was typically the lack of resources combined with an over-reliance on technical debt.

Best practices are useless in a vacuum

I don't have the best memories of those terrible projects, but at the same time I realize that I learned a lot of important lessons.

I learned things that I didn't even realize were important when I was working on well-organized projects.

When we're thinking theoretically of "best practices", it's easy to think in a vacuum where real-world pressures and restrictions don't apply. But in reality, every project is a collection of trade-offs and compromises between different pressures being applied to it. There's never unlimited time or resources. You have to make a lot of difficult choices.

Most technical debt out there doesn't happen because of ignorance or incompetence. It happens because of choices where sacrifices have to be made because of outside limitations and pressures.

Working for Startups

Startups are a good place to find a lot of lessons to learn. I've worked for a few startups and a good number of them are now dead. I consider that a lucky outcome for me, because it has given me a glimpse into what not to do as an entrepreneur.

I've seen all kind of reasons for startup implosion: mis-management of resources, founder disputes and drama, lack of understanding of the target market, waiting too long to ship something.

Interestingly, software development itself seems to be the least likely cause for failure in the cases that I've seen. The customer almost never cares about the code. They care about the problem that you're solving for them.

Meanwhile, in the startups where I worked which did succeed, while I gained a lot of insight about entrepreneurship, I didn't learn as many deep, hard lessons.

Maybe it's because there is really just one way to succeed in entrepreneurship. Make something that solves a real problem for real customers. But there are many ways to fail. There's a ton of ways to do it wrong, and so there's a ton of potential lessons there.

Be a Sponge

I like to think of this as the sponge principle for learning.

What's the best way to learn on the job? Absorb everything you can. Like a sponge.

Where is a sponge going to absorb the most? In places where it's wet and messy. Where there's stuff to absorb.

In contrast, imagine trying to absorb anything by running your sponge over a clean, dry counter top. You're not going to get much out of it.

Be a sponge and learn from what's happening around you. Not just from your own work: learn from your peers, from your managers. Learn from what the company founders are doing. Learn from what's going on in marketing and in customer support.

If in doubt, get out

One last thing. All this has to come with a reminder. Don't stay at a shitty workplace for long. Leave when you can. Definitely leave if you're no longer learning anything.

Watch out for people who talk about company loyalty or tell you that you should wait X amount of time before switching jobs. You don't owe your employer anything beyond the work/salary transaction. If it's bad, get out of there. Burnout is never worth it.

There Are Many Ways to Have a Developer Career

Marek Zaluski — Fri, 18 Jan 2019 16:50:32 +0000

If you're looking for career advice as a developer, here's something you need to watch out for.

There's a lot of great career advice out there. I definitely recommend reading career articles from experienced developers to learn about how they got where they are and what they learned along the way. That kind of knowledge can give you a huge career boost.

The problem is that sometimes it sounds like there's such a thing as "a developer career".

In reality, there's no one single path. There are many. And they can be wildly different.

There are a LOT of career models that can be called a "developer career".

You can be a salaried employee or you can be a freelancer.

You can be full-time or part-time.

You can be a generalist or you can be a specialist.

You can work for startups or you can work for established businesses.

You can work with the hot new tech or you can work with the tried and true stacks.

You can even make a living writing open-source code.

Or you can travel the world as a developer evangelist.

There's a million ways to be a developer.

But, when you're looking for resources online, it's easy to get trapped in a filter bubble if you don't get enough variety of information. It's easy to get bombarded with advice that applies to careers at the Big Tech giants or the Silicon Valley ecosystem.

The world of tech startups, in particular, occupies a lot of the tech discussion online.

The Netflix engineering blog is an excellent tech blog. But Netflix is a unique company with unique challenges. Same thing for Facebook and Google. These are not ordinary companies, but they get the majority of the attention (and you might say that it's for a good reason: they attract the top talent and they pay massive salaries).

On the other end of the spectrum, away from the startup scene, there's the world of enterprise software development. It comes with an entirely different set of values and priorities. It's a different ecosystem. And there's a ton of amazing career opportunities there too.

Being a developer can mean completely different things across different industries and geographies.

In my city there's a solid ecosystem of tech companies and a great developer community. There are lots of opportunities and it's growing. But it's a very different ecosystem compared to Silicon Valley! You need a completely different career approach to succeed.

My suggestion is: figure out your goals first. And try to filter career advice based on what your goals are.

Find a mentor in your industry who has your dream job. Ask them how they got there. Ask them for specific advice that applies to the exact work that they're doing. That's always going to be best source of insight that you can find.

And most importantly: don't listen to the gatekeeping. Sometimes people say things like "real developers do X" or "you're only a real developer if you Y". Build your own career and don't listen to those who tell you that being developer has to fit their particular definition.

PS. I'm not saying that all developer career paths are equal. Some paths definitely are easier than others. Some paths are more rewarding than others (in terms of money and other benefits). Let's be real, not all industries are the same and not all opportunities are equal. The point is that you should look at your own goals, consider the entire realm of possibilities, and then choose what's right for you.

I threw it all away to become a developer

Marek Zaluski — Fri, 04 Jan 2019 13:45:32 +0000

I had completed 3 years of an undergraduate degree in biochemistry when I decided to drop it and become a developer.

In retrospect it was a pretty crazy decision. I was really lucky because I had the family support that allowed me to do this, but it was still a risky move.

The study of biochemistry is actually really interesting. It's all about the internal machinery of cells and how DNA works. I still love reading about life sciences news, especially with new developments like gene editing.

But when I imagined myself working in a lab and building a career in academia, something was missing. I didn't just want to do research, I wanted to make things.

That's what eventually brought me to software. In software I could pick up a computer and make things. There's something so powerful about that. And I didn't need anybody's permission.

Compare that to the world of research and academia. You have to ask for permission, so to speak, at every step of your career. You ask to be accepted by a professor to work in their lab. You ask journals to publish a paper. You ask for funding for your research. You ask permission to speak at a conference. If your work is really good, then eventually it turns around and people start asking you for things, but it's a long path to get there.

Here's why software is different and why it appealed to me. With software you don't need any institution or lab to learn it, you can do it yourself.

You can build and publish your work and nobody's going to stop you.

If your work is good, people will share it and even pay money for it.

That's why I ended up becoming a software developer and it was exactly the kind of career that I was looking for.