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
A team sport Last year I’ve finally obtained the certificate of competency authorizing me to operate sailing yachts so I’ve spent a part of my long vacation on a boat. I love sailing. Sailing is pretty much about the experience and learning the right skills. Every moment on the water is different, and it’s important
If you were hit by a bus tomorrow… If you were hit by a bus tomorrow (knock on wood) would your project get stuck? I still remember when one I worked on did. Well, I wasn’t exactly hit by the bus, but from the project standpoint, it was close enough. We worked on an important
How to divide a resource? Wood Take the wood Take 50% to build dollhouse Take 30% to build a garage Take 20% to build a toy car Now you have 3 pieces of wood and you can quickly deliver three wooden toys. Software developer Take software developer Assign 50% to project A (head) Assign 30% to project
Thanks everyone for attending my presentation. If you have any questions or just want to talk over a cup of coffee don’t hesitate to contact me via your favorite means (I’m social!) Here are the slides from my presentation (available also on Speaker Deck). And a short summary of what it was about if you missed
Imagine what happens when you approach the developer in a middle of that task? Now, if you think he/she can pick up where he/she stopped you couldn’t possibly be more wrong.
When your dev don’t want to follow the process he’s incompliant, isn’t he? But what if the process is killing creation and innovation?
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
Recently I wrote how to deal with requirements in the process of a software development. Requirements are often customers expectations but those aren’t always the same. And not only your customers have expectations. In reality, every person included or interested in a software project has her/his own interests and expectations. And even as a simple developer you
