cdruc

thoughts and notes

Category: Software (Page 1 of 2)

Frontend vs Backend. What goes first?

It doesn’t matter if you’re building a mobile, desktop, or a web app – nowadays pretty much everyone breaks their applications into a frontend that uses the latest, hottest javascript framework and a backend responsible for answering ajax requests.

Arguments on what should go first, the frontend or the backend, are always there.

In my experience, doing either one first will only lead to conflicts and feelings of resentment between the two camps. Front devs will be annoyed because “the APIs are always changing” and the backend guys will be like “why can’t you understand that we had to change x thing?”.

In the software industry, everything is a subject of change. Trying to agree on the API structure and creating dummy JSON files to substitute for the real thing while the backend devs figure out their stuff isn’t a solution.

Even more so, agreeing on such a contract will harm the project in the long term. Each part will try (and fail) to hold on to their part of the deal rather than reaching out to the best solution and approach for the problem at hand.

Next time, keep the team as small as possible (2-3 people), break the application into medium sized components, and start working “as one”. Agreeing on a pre-defined structure never worked in my case. We made great progress when we focused on the same component at once – with the front dev leading the way.

Photo by rawpixel on Unsplash

A book for your ssh connections

Tired of spending time searching ssh connection details through your projects and wikis?

Search no more.

sshls is a small command line app acting as an address book for your ssh accounts.

Once installed, you can start adding records and list them in your terminal.

Putting in the work

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.

Business now, details later

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.

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

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.

Naming things is hard…

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

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

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.

About those “would be nice if…”s

New project. We have our meetings, we come up with a plan, we somehow agree to a budget and then we get the ball rolling, coding our way to the finish line.

As we build stuff, fresh requirements are sent in. “We need this new feature”, “we haven’t thought of that”, “it would be nice if…”, etc. And it’s ok. We saw this coming.

Displaying that list on two columns, making those elements editable, changing that color, size, font, whatever — they seem to have such a low value that we often neglect them. But they pile up and sometimes affect the system in ways you wouldn’t expect, taking an even bigger dip in the budget.

We are bad estimators. But that’s not the worst part. The worst part is that we rarely, if ever, say no to a client.  One reason, apart from the customer is always right and make the client happy, is that it would make us feel incapable, unworthy of our profession. We take saying no as something to be embarrassed of. It’s not.

Saying no not only leaves you with fewer things to do but also leads to a major increase in productivity. It’s far easier to stay focused when you don’t have to worry about the “would be nice if”s.

The devil’s in the details. Control the scope.
Focus on what is essential to create value now. Add the rest later.

Page 1 of 2

Powered by WordPress & Theme by Anders Norén