cdruc

software and stuff

Show menu Hide menu

Putting in the work

August 22, 2018 / / 0 Comments

It doesn’t mean 60hrs/week. It doesn’t mean 30 or 40hrs/week either. In fact, It has nothing to do with the amount of time spent “working”.

It has to do with being responsible and dedicated enough to do your best in being consistent in finding your flow. Every single day. Even for just a few hours.

“People are interrupting me every time”.

Start with you appreciating others flow. Force yourself to avoid interrupting others. Especially when they clearly don’t want to be interrupted.

Try that for a few weeks. If that doesn’t work, continue by expressing your dislike towards being interrupted. Without being a dick.

If that doesn’t work, move on and find another job.

Face-to-face interactions drop 70% in open workspaces

July 18, 2018 /

There’s this idea of collaborative intelligence saying that working closely and putting our minds together makes it easier to achieve goals and objectives. So it’s something we want more of.

You’d think removing the walls and reducing the physical distance between people would raise their level of interaction, leading to an increase in collaborative intelligence and productivity.

Well…nope. Actually, the opposite happens. According to a recent study. the volume of face-to-face interactions drops with about 70% and most of our interactions shift to email and IM.

Removing physical barriers between two, three, or four people works. But it doesn’t scale. It doesn’t work when ten, fifteen, or more people are involved.

Looking at my day-to-day office interactions, most of them are about asking or giving help. Asking for help makes us feel vulnerable. It’s hard enough to do it in front of one person – let alone with fifteen other people, watching and hearing every stupid thing you say.

The study can be found here.

Business now, details later

June 21, 2018 /

Three minutes into a meeting discussing a new feature and we already have a list with tables, columns, flags, objects and methods in our head. It’s involuntary. Whenever we talk about a new feature we jump into programmer mode as soon as we get the chance. We need a model for this, a controller for that, and then we render this component and sync with that API.

Going into too much detail when discussing features makes us lose focus. Programming and figuring out how things should work are hard enough on their own. There’s no need to mix them together.

It’s not only harder for us to reason about the system we’re building. It also creates some kind of lock-in. It’s hard to reverse any of those decisions taken during the meeting. Even harder if you’ve already built something. Because “we discussed and decided that this is how we’re going to do things”.

We act like those initial thoughts are set in stone. Instead of going back to the drawing board and undo the things we’ve done, we build around them, making an even bigger mess.

Refrain from including implementation details whenever you’re trying to figure out how a new feature should work. Get your business rules spot on. Then figure out the implementation.

Cost is no object. No, that’s too much money.

June 18, 2018 /

Driving home from a mini-trip, one of my friends was testing product ideas bouncing them with the rest of us. Most of them were turned down because the financial part wasn’t appealing enough. Like who’s gonna pay 20$ for this product? I wouldn’t – most replied.

I wouldn’t pay 1200$ for a Kanye’s anything. None of his products are worth that much – for me. And I love Kanye.

But people value things differently. There are people willing to pay 8 million dollars for a phone.

The ones buying it don’t do it for the tech (it’s an iPhone 4 after all), for the gold, platinum, or diamonds.

They do it because they want to be the ones with the 8 million dollar phone.

Cost is a factor, but most of the times it’s just another excuse.

The programmer’s gut feeling

June 14, 2018 /

Whenever you feel like an object isn’t really what the name says it is, or that it shouldn’t exist, or that it should exist, but in a different shape, you are completely right.

Stop and re-think things through. Maybe what you find is that you don’t really need that object. Or maybe what you’re trying to accomplish needs two or more objects or an existing one.

That gut feeling telling you that something isn’t what you think it should be is always right.

A Parameter doesn’t have a ParameterRecommendation. The parameter value has a recommendation.

Wrong. We can have n variations of parameter values – we shouldn’t have a different recommendation for the slightest variation.

But we can have some pre-defined ranges. ParameterRange has recommendations.

When cutting

June 7, 2018 /

You find a way to eat fewer calories and you stick with it until you reach your fat loss goal. Restricting calories is painful, sometimes annoying, but not the hardest thing to do.

The hardest thing is watching your strength fade away.

Minimizing muscle loss is part of the goal, and we fight it by lifting heavy; sets of five to seven reps. And because of that, we often get injured. Not the kind of injuries to keep us out of the gym, but painful enough to be noticed.

Those are messages. Messages from your body telling you to take it easier, to lower the weight.

You should listen.

The price we pay

June 7, 2018 /

Although dedication and patience are the most valuable currencies when working on transforming your body, this post is not about that cost. It’s about the actual money we spend, in a form or another.

A membership to a decent gym is about $50/month. You want a personal (shared) trainer, add another $70. That gets you to $120/month or $1440/year.

Apart from gloves, clothing, and good footwear, you also need to consider the time invested. An average workout, unless you’re going to group training, is about 1.5-2 hours. Add at least half hour to get to and back from the gym, and then another half hour to get your shower. That totals to about 3 hours.

You go to the gym four days a week, that’s 12 hrs/week or 48 hrs/month.

Naming things is hard…

May 26, 2018 /

Coming up with clear, expressive and precise names can be challenging and sometimes even infuriating. Why can’t I name this damn thing!? 

We grab our best friend, the thesaurus, and we start digging, jumping from one result to another. And we do that until we find the best word for the thing we’re trying to name.

But finding good names takes time, so I made something the other day that will make you a bit faster. It’s an app for the other programmer’s best friend, the command line. I call it sini and you can find it here.

 

Are these seconds, minutes, hours? Add some meaning to your time units calculations

May 21, 2018 /

Apart from a small todo-cli app and a laravel framework bugfix, I have nothing to show in terms of open source contributions. I’ve always dodged contributing and there are more than enough reasons for that. But the truth is I was mostly hiding behind the “I don’t have time” and “I don’t have a good enough idea” excuses.

But that ends today. Recently I stumbled upon a tweet from Freek (do follow, lots to learn from) asking if there’s a package to convert different time units and assign some meaning by escaping the use of magic numbers when returning stuff like 60 * 12.

The suggested API, Minutes::fromHours(5) is a lot clearer and has more meaning than a random math operation but it implies having separate classes for each time unit. It also prevents me from doing any further conversions on the same value.

Since I’ve never published a php package before, and I was curious about the whole process, I went ahead and created druc/time-convert. It contains a single class and you can do stuff like $time = TimeConvert::hours(5)->toMinutes() and also continue with further conversions like $time->toSeconds().

I’m sure is the smallest and most trivial php package out there, but at least I got to learn the publishing process. 🙂

Help me and others understand your code

May 7, 2018 /

It’s hard to make things work. But it’s even harder to explain how you did it. Here are a few things you could do to help me, you, and others understand your code.

Good formatting. Yes, that space between operators is important. Line lengths, line breaks, blank lines, camelCase, snake_case — they all make a difference. Be consistent, adhere to a guide.

Careless naming. Don’t use abbr. Don’t make me guess. Don’t mislead. Be precise. What is it? What does it do? Why it exists?

Conditionals and switch statements produce different outcomes. Which means I have to read the code again, and again, and again…

Nested loops, nested loops with conditionals 😮 . Same as above, only a million times worse. Get rid of them.

Hide stuff I don’t need to know. I don’t need the details. I want to be able to say “ah, it does this” without knowing exactly how. Write in cascade. Start with high-level concepts and add more details as you go downstream.

Make smaller things. It increases the number of files, classes, and methods and makes it harder to reason about the whole system. But that’s the idea. I don’t want to reason about the whole system. I can’t. Nobody can. I’m more efficient reasoning about small things. One at a time.

Don’t fall into the “I’m the only one working on this” trap. There are at least two people working on a project during its lifetime. The first one is you. The second is the you after a few months.

Put some more care into your code. Name stuff a little better, split classes and methods into smaller ones, make it look and read well.

It's not your code. It's our code.

« Older posts

© 2018 cdruc

Theme by Anders Norén — Up ↑