Page 4 of 5

Where are all the normal t-shirts at?

After my first round of decluttering, apart from one pair of jeans and a few shirts, my wardrobe was pretty much gone. Ironically, switching to minimalism has me buying more stuff.

The pair of jeans that survived the first round of decluttering was available for purchase. So I bought another six pairs. Placed the order, received it in a few days. Easy.

But I had no t-shirts, so I had to go and buy some.

I spend a whole day, going from store to store, searching for a nice, clean, slim fit t-shirt. No luck.

Every year is harder and harder for me to find clothes. I know “fashion” changes with every generation. But I’m not that fucking old yet.

Going minimalist #2

The first round of decluttering is finished. 180 items have left my room. 87 of those are pieces of clothing. Funny, I was always mad I don’t have enough pants. It turns out I had 25, but only wore the same five pairs over and over again.

180 items is not a huge number. I was expecting to be more than that. What surprised me was that I wear less than half of my clothing on a day to day basis. Same shoes, same shirts, same pants. I guess we all have our favorite clothes.

The thing I found it to be the hardest, is to let go of the few objects that hold sentimental value for me. I couldn’t find the power to let them go, so I kept them for now. But I’m confident they’ll find their way out on the next rounds of decluttering.

Dust off your inner designer with tailwindcss

Designing UIs is hard, especially if you’re a backend developer. When bootstrap came along everybody was cheering. And so did I.

No more wasted hours on fiddling out the interface. Look up the documentation, copy&paste the examples and adjust to your needs. It simplified everything for the non-designers.

But it also crippled our already modest design skills. It made us lazy.

Before bootstrap, we were at least trying to make things look nice. Now we’re just changing a few variables here and there pretending it’s different. Only it’s not.

Because bootstrap is a component-based framework, everything that comes out of it looks and feels the same. Forms, buttons, alert screens, proportions, modals, everything.

Tailwind doesn’t have pre-built components. You have to unleash your inner designer everytime you want to build something new.

Prototyping with tailwind is slow. Painfully slow in the first days. You have to always have the documentation by your side to look stuff up. There are so many utility classes! But fear not.

Once those few days have passed, everything gets easier. I would even argue that tailwind has a shorter learning curve than bootstrap. Because you type in every class on your own, rather than copying&pasting full blocks of code from one place to another. All those tiny utility classes get ingrained in your memory real quick.

About the clones you end up with by using bootstrap, yes, you might say that it comes down to laziness and lack of creativity. That you can choose to use as much or as little from the framework.

And I agree.

But I, for one, do not mind being pushed towards becoming more creative. By not having a full blow set of components, tailwind does just that.

I’m not calling back

2018 was a great year for businesses in Romania.

Last week my car rotors ran out. The brake pads were to be replaced as well. And since I needed an appointment, I might as well do a full inspection.

I went online, searched for nearby auto services, read all the reviews, decided the winner. Called it and asked for a quote.

“We’ll call you later”, they said.

I had a dentist appointment. Something intervened and I had to cancel. I called a few hours before to reschedule. “We’re not at the office at the moment and we don’t have access to our scheduling software. We’ll call you back as soon as possible”.

4 days have past and none of them did.

I was in shopping mode. All they had to do is to call back, do a good job, and they would’ve had me for years. It’s not like anyone changes their dentist every week – unless they do a terrible job.

There are dozens of people just starting out, with no clients, hoping to be given the chance to do their best work. I’m not calling back.

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.

Doing what others are doing

The second our eyes open for the first time, we start watching and analyzing the people around us. We start doing what they are doing. We’re smiling, laughing, and eventually walking.

We learn everything from them.

But somehow later in life, I don’t know the exact moment, following others, doing what they are doing, asking for advice, becomes something we are ashamed of. Maybe it’s because we should know better by now. Or because people might think we’re stupid. Or that we don’t have our own opinions.

That’s stupid. We can’t be good at everything. Not before doing what other people did and certainly not before listening to their findings. And no. Sharing the very same opinions with tens of other people is not “copying” or being unopinionated.

Like it or not, we’re pretty much like an open-source project. Everyone you follow, listen, or read, contributes to your development as a professional and as a human being.

Get better at admitting that. Get better at following people.
They don’t know it all, but they might know more, or better than you.

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.

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. Decisions taken during that meeting are harder to reverse – because multiple persons gave their OK on them. 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 come up with a better idea, we build around or on top of whatever we initially agreed, 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.

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 most likely right.

Stop and reconsider. Maybe what you find is that you don’t need that object. Or maybe what you’re trying to accomplish needs two, or more objects, or one that already exists.

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

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!? 

In search for a proper name, we grab our best friend, the thesaurus, and 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 faster. It’s an app for the other programmer’s best friend, the command line. It’s called sini and you can find it here.

© 2019 cdruc

Theme by Anders NorénUp ↑