71 articles, 4 books. Go to books ↓

Sometimes we forget that other people have faced the same problems we face today in software development.

A Collection of quotes and paraphrases for developers from around the web.

When a developer suddenly steps into the Tech Lead role, it is not immediately clear what to do differently. Instead of taking on the Tech Lead responsibilities, they stay heads-down writing code.

People have been debating for decades about the notion of a software developer who is "elite". Sometimes this person is described as a "rockstar developer" or a "10X" developer.

The impostor syndrome, is a psychological phenomenon in which people are unable to internalize their accomplishments. Despite external evidence of their competence, those with the syndrome remain convinced that they are frauds and do not deserve the success they have achieved. Proof of success is dismissed as luck, timing, or as a result of deceiving others into thinking they are more intelligent and competent than they believe themselves to be.

What many companies don’t realize is that implementing a scalable process is just as important as scalable technology.

... but unfortunately they do, and those things go into production.

Learning something new, a new skill, a new way of doing things, is super inefficient, takes a hell lot of time and you don't know whether or not you'll ever become good at it. It might turn out to be a waste of time. But there's no other way.

You weren't hired to do specific fully-defined tasks, but rather to further the goals of the team and company. It's up to you to learn voraciously and think critically about the problem, the solution, the constraints. It's up to you to become fully aware of all you're contexts - business pressure, schedule, financial considerations, deployment strategy, etc etc.

When it comes to writing code, the number one most important skill is how to keep a tangle of features from collapsing under the weight of its own complexity.

What separates the good people from the really good people isn’t what they know; it’s how they think. Obviously knowledge is important—critical in some cases—but in a field that changes so quickly, how you go about acquiring that knowledge is always going to be more important (at least in the long term) than what you know at any given time.

Developers are more than aware that certain aspects of their job are considered unchartered territory by their boss – but what about the parts of software development that they shouldn’t be so clueless about?

Netflix defines Chaos Engineering as the “discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.”

The nicest thing you can say to a project manager or your boss is something like “I am done with my task / project“. Everybody loves people who are getting things done.

Failure is part of engineering any large-scale system. One of Facebook's cultural values is embracing failure.

“Engineer” is an aspirational title in software development. Traditional engineers are regulated, certified, and subject to apprenticeship and continuing education. Engineering claims an explicit responsibility to public safety and reliability, even if it doesn’t always deliver. The title “engineer” is cheapened by the tech industry.

Investing in your ability to learn is much more important than investing in any particular language, tool, or technology. Avoid the hype and learn how to learn by constantly learning.

Anyone who has worked on a large enough codebase knows that technical debt is an inescapable reality: The more rapidly an application grows in size and complexity, the more technical debt is accrued.

Our brains are naturally limited. This can be a curse, or it can be a gift, depending on how you look at it.

Hot or not? From the Web to the motherboard to the training ground, get the scoop on what's in and what's out in app dev.

Developers should dig deep to understand their project's stakeholders.

The moment one customer pays you a lot more than any other customer, you’re no longer a product company, you’re a services/consulting company again.

Half of what a programmer knows will be useless in 10 years.

I can’t think of a single large software company that doesn’t regularly draw internet comments of the form “What do all the employees do? I could build their product myself.”

Commit to excellence. Follow through with pro-active practices. This is how you gain the trust of your employer/customer and the respect of your peers. In short, be a mentor before you have a student, because you're expected to lead by example, and the junior programmers will look to you for guidance.

There's a strange dichotomy that college doesn't prepare computer science majors for: knowing how to program is a huge benefit if you want to create something new and useful, but as a programmer you're often viewed as the implementer of someone else's vision--as just the programmer--and have limited say in crafting the application as a whole.

Few things are guaranteed to increase all the time: Distance between stars, Entropy in the visible universe, and Fucking business requirements. Many articles say Dont over-engineer but don’t say why or how. Here are 10 clear examples.

I can't tell you how nice it is to have software in production on a boring stack. It gives you freedom to do other things.

You have never been paid to write code. In fact, code is a nasty byproduct of being a software engineer.

If you write code for a living, there’s a chance that at some point in your career, someone will ask you to code something a little deceitful – if not outright unethical.

Here are some talks which have given me new insight into programming, and in particular what good programming is and isn’t.

Agility is a good thing, no doubt, and the Agile Manifesto isn’t unreasonable. Compared to a straw-man practice called “Waterfall”, Agile is notably superior. Yet, so much of Agile as-practiced is deeply harmful.

"The most dangerous thought you can have as a creative person is to think you know what you're doing."

The New Year is here and New Year's Resolutions are in full effect. For most people, this means going to the gym and eating better, but for organizations, this usually manifests itself as a lot of activity around new initiatives to deliver the next "Big Thing"...

We asked our open source community to share the comics they found most profoundly described coding, via our news site. Here are their 25 most upvoted comics.

What parts of my knowledge are now obsolete? What parts are long-lasting? And most importantly, how can I make sure that I always get better as an engineer in the face of all those fleeting frameworks and libraries?

id Software co-founder John Romero tells the early story of the game company in this GDC 2016 talk and lists the programming principles that guided them towards the rapid development of many games including Doom and Quake with a very small team.

If you are writing a web app — a great web app, a fantastic web app, THE BEST EVER WEB APP — you do not need a container orchestrator. You need a PaaS. You do not need 5 different ways to deal with rolling out new versions of your app. You do NOT need to be able to configure and tweak your database. Do not manage your own database!

Polyglot programming is sold with the promise that letting developers choose their own tools with complete freedom will make them more effective at solving problems. This is a naive definition of the problems at best, and motivated reasoning at worst. The weight of day-to-day operational toil this creates crushes you to death.

To completely remove programmers from the equation would require essentially a human level artificial intelligence. And if I start seeing near sentient robots walking around, my first thought is certainly not going to be, “oh no, it’s going to take my job!”

How do you rate a development team? It’s not a simple challenge, and to get a full answer would take a considerable investigation and a lengthy report at the end. Thankfully, Joel Spolsky came up with a simple 12 question test to make this process relatively painless, named “The Joel Test”. The test isn’t perfect, and doesn’t claim to be, but what it does give you is a solid basis to work from to find out those last few details.

However expert, we still make mistakes. Of course, nobody would deny that. Go up to literally anyone in the field, ask, “do you ever make mistakes,” and you’ll hear “of course” or at least a tepid, “every now and then.” But a difference exists between making mistakes in the hypothetical and making a specific mistake in the moment.

What I want to show is that we can have this very simple and basic application that looks very, very reasonable, and show a bunch of issues and potential bugs that can hide in it and surprise us in nasty ways, and that it's hard to really feel safe about any code out there.

It used to be fairly clear when we reached for libraries. We reached for jQuery to help us simplify working with the DOM, Ajax, and handle cross-browser issues with JavaScript. We reached for underscore to give us helper functions that the JavaScript alone didn't have. As the need for these libraries fades, and we see a massive rise in new frameworks, I'd argue it's not as clear when to reach for them. At what point do we need React?

One of the most important questions that are raised during development of software project is the economic benefit of software architecture. The question is commonly asked by business people, the owner of the software and even by software developers.

We like to think that we’re hyper-rational, but when we have to choose a technology, we end up in a kind of frenzy — bouncing from one person’s Hacker News comment to another’s blog post until, in a stupor, we float helplessly toward the brightest light and lay prone in front of it, oblivious to what we were looking for in the first place. This is not how rational people make decisions, but it is how software engineers decide to use MapReduce.

We’re constantly deploying code at Reddit. Every engineer writes code, gets it reviewed, checks it in, and rolls it out to production regularly. This happens as often as 200 times each week and a deploy usually takes fewer than 10 minutes end-to-end. The system that powers all of this has evolved over the years. Let’s take a look at how it’s changed (and how it hasn’t) over all that time.

Becoming a rubber duck is not terribly difficult, though it does take some practice. Here's how it works: you listen to your coworker's problem. That's it. Don't offer opinions, don't espouse your favorite Javascript framework, just shut your mouth and pay attention. Much of the time, they will solve the problem through the mere act of explaining it to someone else.