Recently I switched jobs, and as part of this change, I’ve been introduced to a whole new tech stack. RabbitMQ 🐰, Java Spring, Docker, etc. (meaning more subjects to write about 😂). Most of the technologies I use on a daily basis consume YAML as their configuration. In this post, I’ll try to illustrate what I’ve learned (and from where) while trying to understand this new world.
Here is a situation that I am pretty sure every team or individual contributor has encountered throughout his career. You get well-defined requirements, review them, ask questions, adjust them with your product owner, and prepared one heck of SW design. Soon after, the implementation phase begins, and a few hours or days before the end of the story, the business calls and asks for an extra feature (or change) to be implemented. WHAT?!
Usually, the project manager\product owner is responsible for filtering out these requests as “must-haves” or “nice to have”, but there are cases where…
Everybody, at some point, will encounter a challenging colleague. Being able to deal with a person like that is part of developing conflict resolution skills and learning to overcome those setbacks.
In the following paragraphs, I will try to illustrate how I deal with these situations.
To be honest, we have to know that not everyone we struggle with is someone who tries to give us a hard time, as every relationship will have friction moments. …
There are many ways you can determine whether a new feature will add value to the product or turn out to be a complete waste of time. For instance, you can undertake user research, analyze the demands of the market, and study existing solutions. However, we (developers) have a fantastic tool in our sleeves: Developing a running project that demonstrates the proposed solution’s key ideas is your optimal option — in my opinion.
Just one small thing: what do I mean by “demo”?
Does the team complain about bottlenecks that slow them down? The same things happen over and over again? Luckily there is a simple practice that, in my experience, can help instantly. What I actually mean is, does your team take part in a retrospective meeting? No?! 😱 Make sure to adapt it ASAP, no matter which software development methodology you follow.
“Those who don’t learn from the past are doomed to repeat it.” — George Santayana
A retrospect meeting is a safe place. Everyone can say what’s on their mind without being judged for their opinions or getting negative feedback…
You’ve prepared a new resume, searched for challenging positions, submitted your CV to various companies, participated in many interviews, asked your interviewers about the working environment, considered your culture fit. Eventually, you’ve received several job offers, prioritized and weigh them down …. and finally, you’ve agreed to take one. 🤗
The exciting day has arrived — your first day on the job.
I bet you remember it, the thrill of starting a new place, a new position. You feel it in your bones. You want to bring value ASAP, but how? What’s the…
Don’t give up, keep up with your efforts to find other ways to understand the bug’s root cause. I know it can be frustrating. The agonies with the process can be ruff. But, you’ve got it, you solved many in the past, and you will solve this one too. It is part of your job.
Imagine the following situation. One of your experienced colleagues talks about doing some work, which she’s passionate about and sure it will provide better results for the team. She has fire in her eyes when she talks about replacing technology X with Y.
You feel it right into your heart. Your colleagues seem to agree with her. She’s so right. Though, she hasn’t proven the business value of her idea (just the technical aspects of it). You are tempted to agree too. That moment, I was there many times.
That’s the bandwagon effect when you align your opinion with the…
The aspects of code complexity are broad; one of them result from the design of our code. Design weight is the cognitive effort reading and maintaining your code — a metaphor used for emphasizing how it weighs down your progress.
The main symptom (as I encountered) is code that forces you to remember specific areas to connect the dots between them. While relying on your memory has its benefits but also a capacity, leading to losing details, causing you to re-read with an effort to memorize it, reducing motivation to be engaged with the product.
“Keep it simple, as simple…
Senior software engineer. Love to ask questions and write about their answers.