into Software Projects
There are only two hard problems in Computer Science: cache invalidation and naming things. – Phil Karlton We name and name and name. We name variables, functions, arguments, classes, source files, and the directories. Proper naming makes the code easier to read. Intention-revealing names The right name tells you why the variable, function or class
You can probably come up with a bunch of answers: the computer, the client, the cloud, the company… But first and foremost you write code for other developers. And for your future self. I mean, the computer will understand anything you write (as long as it compiles). And it’ll behave in the exact way you
The production system broke last Tuesday… I got a phone call last Tuesday around 8 pm. The operator told me a daily task broke in the production and I had to take care of it as soon as possible. I turned on my laptop and connected to the customer’s system. I checked the error logs and
Last Sunday I’ve talked to a friend. She just recently picked up Java. We’re about to start a learning experiment: she is going to learn how to write code in Java, I’m going to help. Work out a plan and set up exercises. I decided to blog about what we’re doing here. The “learning” posts will be visible
Imagine yourself sitting in front of a compiler, tasked with fixing a small bug. But you know that as soon as you say “I’m finished,” another developer – or worse, your boss – will be examining your work. How do you feel? Anxious or encouraged? As software engineers, we take pride in our work (as well
We, software engineers, tend to be protective of our work.
We get anxious about showing our code.
Unfortunately, the wall we build around “our” code is a perfect formula for a disaster.
Luckily, doing the things that scare us more often makes them less scary.
