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 … Continue reading To meet or not to meet? Understanding the hard language of expectations…
Have you ever worked on something for a long time, only to realize in the end that you've completely missed the point? Probably. this is how to ensure you know what's about to be built.
We didn’t become programmers because we like working with people. But most of a software is created by teams. So like it or not, you must effectively communicate with others. Here's how.
Here I go creating 2-people Kanban board for our current project efforts so that we can easily see how our work goes and share it with my Junior (he's a Junior Dev, but he's got more IT experience than I in fact... he did a career sidestep just recently). And the first thing I hear is: … Continue reading IT allergens: Agile.
On every project, there are things you know and things you don’t know. When it comes to the difficulty of the unknowns, you can make progress only thanks to assumptions. Without assumptions, you’d never get anything done because you’d be frantically proving everything before you’d move on. However, when they end up being false, they can affect your project outcome significantly.
We, software developers, tend to have some bias towards cutting edge technologies and, in a perfect world, we'd only use them. It's efficiency driven so that's great but sometimes we forget that the code we write is written first to benefit the human and only second for a computer to understand. And that's why we … Continue reading How to C.A.R.E about software projects?
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.
Ok, I get it. You are a software engineer... And you probably decided to be a software specialist because you enjoy programming. so why is it that you ought to know the business side of the project?