CodegazeRants

Twenty Twenty-Five

2025-12-30T00:00:00+00:00

The last time I did one of these I couldn't outsource a visual aid to LLMs. I didn't do that either this time, since it takes a bit of the fun! So I made this in Figma because some traditions die hard, even when they're inefficient.

But getting into our purpose of gathering today, without any ramble. 2025 was interesting. It was a year of change.

Last January, after 8 and a half years I left Transifex. I loved my time there as a leader. Difficult decision but change was inevitable. I had the urge to join a team with different challenges. Scaling, diversity and overall meeting new people.

On Changing work

When changing work these are some common patterns showing up. You've either heard about them or you're living them.

The Newbie. That's right. You get into a new building and you have no idea even where the bathroom is. Everything is new although so familiar from years of experience. Which makes it even more annoying. You mixup Lisa with Liza and you called twice George as Michael.

If you felt comfortable you would ask the junior engineer to tell you how to tie your laces in this company. You don't know where the bodies are buried. You can make assumptions, but taking action with assumptions only will make you look like a fool.

Take a breath, stand up. Shake this thing off. Moment of truth.

The first 90 days is not just a cliche. You need at least three months to understand how the kitchen is built. Up until then, do something silly that might help people. Ask to contribute to something that makes sense. No one is expecting to be your full self in day 1 or day 10. If they do that might be a first "code smell". Maybe things to refactor in the future.

The Lack of Rapport. A few months ago, if the CSO said something unorthodox, you had options. You could raise your hand respectfully. Or you'd catch your manager's eye across the table and they'd handle it. In an emergency, you'd exchange sanity checks with your peers, maybe have an internal chuckle, without others noticing, if someone makes a joke about it.

Now you're in a meeting and someone says something that lands wrong. You don't move. You can't raise your hand because you don't have the context yet. Your manager isn't going to help because you don't have that history. Your peers are still peers, not allies.

So you sit with it. You take the note. You move on.

You can't be yourself yet. You have to be careful. Measured. You're negotiating every interaction instead of living in ones you've already built trust in.

Sounds a bit heavy. You can't hold back forever waiting for comfort. And you can't blindly trust everyone. The middle ground is doing something slightly silly and seeing who laughs with you instead of at you or something totally dumb and see who will have the guts to save you from embarrassment. "You got something in your team" moment. That's how rapport actually starts. Not through careful professionalism. Through small risks.

It comes. Not on day one. But it comes.

Overload. There's a conundrum nobody mentions. Either the company has good onboarding and you're drowning in information at 1000mph, keeping maybe 1/100 of what you hear. Or the onboarding is a lunch and learn and you're supposedly ready to go. Either way, you're overloaded.

I heard someone describe it once as "being fed with a hose." That's accurate.

You're in meetings where you have no idea what's happening. Three acronyms you don't know. A reference to a decision from six months ago. Someone asks your opinion on something that matters and you freeze because you don't have the context to have an opinion.

This is where people make mistakes. They try to sound smart. They make calls they shouldn't make. They nod along to things that don't make sense.

Here's what I learned. Say no. Or not no, but respectfully push back. "I don't have enough context yet" is a complete sentence. People will respect you more for admitting it than for pretending.

Keep notes. Especially acronyms. The same thing gets described five different ways by five different people and it'll make you insane if you don't track what they're actually talking about.

And when you meet someone, be present. Fully. You won't remember what they said, but you'll remember if you were actually there or just physically present.

It takes time. The 90 days cliche. You're not supposed to have it figured out by week one. Anyone who expects that is signaling something about the culture. Pay attention to that.

On Writing

Oh my! Back to releases every two weeksish.

I started publishing again and at the same time I did something that I haven't done in the past. I started having a schedule. A better cadence. I was always more on the path of "when it's time, inspiration will come" or "it's ready when it's ready".

This time I pivoted. I moved more into, don't wait for ideas to be perfect. You have something you like. Publish. Don't stress about making mistakes.

Why? Because I had the thoughts, I was adding them on paper. And they were sitting there, waiting for the perfect timing that never came. Or I was always busy. It's best to say, it was just time to do it.

The Manager Problem Problem was sitting in my drafts for way too much. Once I read it after much time, I repurpose and rewrote it, and although I knew it wasn't perfect I published it. It had mistakes, I got feedback. I updated it. No one was harmed.

Now these are the articles I published. Ten whole since August...ish. Five for leadership, two for career and three about software. This work gets me to my happy place. Take a look if you haven't you might see something you like:

The Scale

What can I say about this year? Where does it fall on the scale?

On good. I wanted to start over on something new. This has a toll. You pay it and it can work or not. In the end it did. Most of the times it does one way or another. It might take time, but it will.

So starting over, as hard as it is, is sometimes the only way to actually move forward. The work ahead is the same as the work behind: show up, stay consistent, write the thing, and the bathroom is third door on the left.

The Manager Problem Problem

2025-12-15T00:00:00+00:00

It's Monday. You're sitting across from your manager in the 1:1 you rescheduled twice.

You've prepared for this. Careful words. Not accusatory. Just the facts. The pattern. How it's affecting you.

"Last week in the leadership meeting, you presented the scaling analysis that I prepared and my contribution wasn't mentioned. This has happened a few times now. And I notice I'm becoming hesitant to bring my best thinking forward".

They listen. Actually listen. They nod at the right moments. They ask clarifying questions like they're trying to understand. Halfway through, they say "I hear you. That's not my intent.".

You believe them. Or you want to. Either way, a relief comes with this. Finally they get it.

They suggest a few things. They will be more careful. They'll make sure to credit the team. You'll check in more often. Nothing earth-shattering but it feels real. You write it down. They seem to take it seriously.

And the meeting ends. You leave feeling lighter than you have in weeks.

Friday, you're in the all-hands. Your manager presents a project update. It's work your team did. They talk about the problem you identified, the approach you designed, how it solved the scaling issue. They never mention your name. They took ownership. The audience congratulates them.

You wait for the pit in your stomach to show up. It does. Then it hits you. Not anger. Something worse.

Clarity.

The conversation on Monday didn't happen. You had it. But they didn't. They nodded. They agreed. But they're already operating like the conversation never existed.

If they're operating inside the rules this way, they know exactly what they're doing. And more than that, they know you can't prove they're not. You can't point at this all-hands and say "you promised". They were careful about attribution. They mentioned the team. But they framed it in a way that made it sound like their insight. Their implementation.

Technically, they didn't lie.

But you both know what happened. And there's nothing concrete enough to report, nothing clear enough to escalate, nothing that would make you sound like anything other than someone with a problem.

That's when you realize. This isn't a bad manager. This is someone who learned how to operate inside the rules in ways the system will never catch.

And these are two problems really.

The first is that someone is making your life miserable at work. The second is that the person you are supposed to talk to... They are the problem.

My condolences. You have a Manager Problem Problem.

The Manager Scale

The thing is that most managers fall into categories you can actually do something about.

Inspiring, Good or Ok managers can be talked through. You explain the impact. They reflect. They adjust. It's a bit awkward but fixable.

Bad managers either don't do the work or can't. If you have tenure and credibility, you escalate through reviews or skip-levels. You can move teams. It's hard but solvable.

Toxic managers are a whole different case. They break rules explicitly. They cross lines that are clear and documentable. HR has a playbook. Legal gets involved. There's a process, even if the organization is slow to use it. The stakes are high.

But there's another type. The one sitting across from you in that 1:1. They listen when you confront them. They nod. They agree.

The manipulative manager operates inside the rules in ways the system was never designed to catch. They don't break policy. They exploit the space between what's policed and what's possible. They hear your concern and acknowledge it. Then they operate exactly like you never said anything because nothing they do is technically wrong.

When you confront them carefully, they listen. They ask questions. They make small commitments. But in practice, the conversation evaporates. They're not gaslighting you deliberately. They're just already moving on to the next thing, and the promise was never written down, never formalized, never part of the actual system.

You think about escalating. But escalate what? They didn't say anything reportable. You don't have evidence because evidence requires a violation, and they never violated anything. They're good at this.

They throw people under the bus, but only when it matters and only behind closed doors. They befriend people who help them and ignore people who don't. They usually show you how to cook and at the same time they use chaos as cover, proposing half-baked frameworks as solutions while the team does the actual work. They're relentless about outcomes and invisible about methods.

When you report them, you sound emotional. Unreasonable. Like you're the problem because you're pointing out the problem.

That's the loophole. That's the cunning type.

Why The System Can't Catch Them

Here's the brutal part. Every organization is perfectly designed to get the results it gets.

Most systems work fine. They catch obvious crises. They escalate law-breaking. They support good managers who make mistakes.

But the system fails to diagnose these cases because it was never designed to catch subtle, invisible problems. It measures outputs. Metrics are usually high. Deliverables are predictable because the team compensates. The system sees success and stops looking.

Organizations measure what breaks, not what was prevented from breaking. They track who fixes fires, not who prevents them. So the person who operates inside the rules and delivers numbers looks fine. The fact that the team is burning out, that people are quietly leaving, that work that should take three months takes six because someone's taking credit and creating bottlenecks... that's invisible until it manifests as attrition.

By then, the math has already been done.

Leadership might know. They see exit interviews. They notice quiet migration. They hear whispers. But they make a calculation. A manager who delivers is valuable. The cost of replacing them is concrete. The cost of keeping them is hidden. It only shows up when people burn out or quit. And by then, there's plausible deniability. People leave for lots of reasons.

The business optimizes for continuity, not for your sanity. And from their perspective, the invisible labor holding everything together is just how work happens.

So sometimes, even with the best intentions, the truth is this. They know. They calculated. They decided to keep the manager anyway.

What Actually Happens When You Try

You already know this part. You lived it on Monday and Friday.

You confront. They agree. Nothing changes. The conversation didn't happen because conversations aren't policy. So they can agree on Monday and operate differently by Friday without technically breaking anything.

You think about escalating. But to who? You don't have concrete evidence. You can't quote them saying something reportable. You have a pattern, a feeling and the knowledge that they're smart enough to never leave a trail.

If you push too hard, you become the problem. Not because you're wrong but because you're making noise about something that exists in the space between what the system measures and what actually matters.

The Odds

You are in a tough spot. That's the ugly hard truth.

If your manager falls into the Good or Toxic categories, you know what to do. Use your 1:1s. Use 360 reviews. When things get serious, escalate through HR. The framework exists, even if it's not perfect. It was built for these situations.

But if you're dealing with a Manipulative manager operating in this space, the standard frameworks don't help you. They weren't designed for this.

First, stop expecting things to change. If you're in this situation, this is the hardest part and the most important. You keep hoping they'll see what they're doing. You keep thinking if you just explain it better, document it more clearly, find the right words, something will click. It won't. If they're operating this way, they know exactly what they're doing. Nothing you do will fix this.

Once you accept that, you can think clearly about what comes next.

While you're still there, protect yourself. Set boundaries. Stop volunteering for their half-baked projects. Stop hoping the next 1:1 will be different. Compartmentalize work so it doesn't bleed into your life. Document conversations not because you're building a case, but because you'll need reality checks. When they rewrite history, you'll want proof that you're not losing your mind. When they try to blame you for something, you'll want receipts.

Find your people. You need to stay sane. You need to decompress. Talk to peers who see what you see. Build relationships with other managers. You need allies who can confirm you're not imagining this.

If skip-levels exist and you trust the person above your manager, test the waters carefully. Sometimes there's a path to switching teams or reporting lines. But be realistic. Most organizations won't move you away from a "high-performing" manager just because you're unhappy. And if you push too hard, you become the problem.

Those are the things you can try. But here's what you really need to decide because it affects your life.

Are you staying or leaving?

If you're staying, make peace with it. Maybe the rest of the job is worth it. Maybe you can't leave right now for financial or personal reasons. Maybe you're waiting for them to move on first. That's fine, but be honest with yourself about what you're choosing. Stop fighting battles you can't win. Protect your energy. Do your work. Collect your paycheck. Plan for when things change.

I've seen people stay longer, outlast their manipulative manager. Because sometimes the manager moves on, the culture shifts, someone above them finally acts. It happens. Not often. But it happens. And if you're still there when it does, you'll understand how fragile the whole thing was.

The truth is you probably won't be there six months from now. Because things break. And you'll finally accept that you're not the thing breaking.

So, If you're leaving, start now. Not in six months when you've documented enough or tried one more escalation. Now. Update your resume. Talk to recruiters. Reach out to your network. Life is too short and your career is too valuable to let it stagnate under someone who uses you to advance themselves.

No Fireworks Leadership

2025-11-30T00:00:00+00:00

Third time in two months we had an incident. Five minutes of downtime. Two engineers at 8 PM trying to magic it back to life. The fix wasn't clear. Reverting to the previous deployment was faster. If we were lucky, everyone would keep living their evening and we could figure out what actually happened next morning.

So we reverted. Seven minutes down.

One of the engineers sent a message to the channel. People sent their emojis. The CEO sent his own message thanking the two of them for their response.

I also sent my congratulations to the team. These were some good reflexes. Having the product down for longer would have been a hit for our SLAs and our customers. We managed to fix it before getting a user report so they indeed were the heroes of the day on that Wednesday.

I meant every word. They stayed calm. They made good decisions under pressure. They deserved the recognition.

But something still didn't sit right with me.

The Work That Never Happened

Our industry loves heroes. The engineer who stays up late to solve the bug. The firefighter who responds to chaos with clarity. We build these stories. We celebrate them. We promote on them.

But I was also watching two people get celebrated for being excellent at something that should never have needed to happen.

There was another team somewhere in your org. Quieter. No emergency channels lit up at night. No all-hands messages. No CEO shout-outs. Stable complex deliverables. The deployments are smooth. Six months ago, an engineer anticipated a scaling problem and redesigned the data flow. Not flashy work. Nobody ran it as a project. It just works. So there's nothing to solve. There's no story.

That team is doing the work.

They prevent crises. And nobody's going to thank them for it because the world kept running like it should.

Prevention Work

This pattern doesn't just apply to engineers. It shows up everywhere the work actually matters.

A manager notices someone has gone quiet in meetings. Ask better questions in a one-on-one. The person admits they've been thinking about leaving. Nobody else knew. Leadership didn't know. But the manager noticed the shift and asked. They figure out it's not the work, it's feeling unseen. They make space for them to lead the next project. Three months later they're engaged again. They never actually leave.

Another team lead sees tension building between two people. It hasn't blown up into conflict yet. But they feel it. They have separate conversations with each of them. They reframe how they work together. The conflict never becomes a crisis because they caught it before it needed to be a crisis. They help their function work.

A security engineer reviews the codebase for patterns that could become vulnerabilities later. She flags an auth flow that works now but has architectural debt. Nobody's exploiting it. There's no incident. But she catches it before it becomes a problem. She works with the team to fix it quietly. Nothing breaks because nothing was broken yet.

In all three cases, the result is quiet. No incident report. No resolution story. No tickets. No metrics. Just the thing that didn't happen.

And quiet work disappears. You are still preventing. And prevention looks like nothing happening. No fireworks around it.

Why The System Can't See This

This is where both things converge into the same structural problem.

You can see the heroes. They make noise, generate data, strategically talk to the right people. The engineer who responds to incidents creates incident tickets, response times, resolution stories. The manager who handles a crisis creates escalations, decisions, visible outcomes. These are measurable. Reportable. Concrete.

Prevention work generates nothing. No tickets because nothing broke. No metrics because nothing failed. No story because the thing that could have happened didn't happen. In any system that measures what breaks and who fixes it, prevention work is invisible by default.

At small scale, this is manageable. A manager knows their team. They see prevention work happening. But as organizations grow, you need metrics and dashboards to track performance across multiple teams. And those dashboards measure incidents, not prevented incidents. Response times, not problems avoided. So the system reinforces itself. The things you can measure get resources and attention. The things you can't measure get squeezed out.

Add promotion systems on top of that. Career growth is tied to impact. Impact is tied to what's measurable. So people optimize for measurable work. Reactive work. Firefighting. Because that's what generates the data that gets you promoted.

This isn't malicious. It's structural. Organizations didn't sit down and decide "let's only value reactive excellence." They built systems to measure and manage performance. Those systems naturally gravitate toward what's visible. And prevention work, by definition, isn't visible.

This is how stable systems become unstable. Not because people stop caring about prevention. But because the org architecture makes prevention work invisible and reactive work visible. So over time, the people who would do prevention work either adapt and start firefighting instead, or they leave for somewhere that values what they actually do.

What Leaders Actually Do

At some point you realize the system isn’t malfunctioning. It’s doing exactly what it was built to do. It measures what breaks. It rewards who fixes. It celebrates visible outcomes because visible outcomes are easy to quantify.

And if you’re a leader inside that system, you don’t get to wish it behaved differently. You have to lead inside the reality you’ve got.

Start where your reach actually matters. In your one-on-ones, ask a simple question: "What did you stop from happening this week?".

Write it down. Because prevention evaporates faster than anybody thinks. It looks like nothing. It feels like nothing. And unless someone captures it, it gets treated like nothing.

Bring those notes to performance conversations. Read them back.
“You redesigned the data layer and stopped three scaling issues before they existed.”
Say it clearly. Because the default conversation is always about who sprinted into the fire. Someone has to speak for the people who built a world where the fire never started.

If you manage managers, make them do the same. When a team has zero major incidents, pause the room. Ask why. Make them say the names. Because if they don’t, the system will treat stability like luck. And luck doesn’t get rewarded.

Push upstream where you can. If you have the authority to question what the company measures, do it. Audit your dashboards. Ask why you’re tracking reaction time but not resilience. Ask why you can tell me how many things broke last quarter but not how many were avoided.

This is the part that feels like fighting dragons with a broomstick. You’ll lose fights. You’ll annoy people. You’ll get the quiet "is this really worth it?” look from the folks who love their dashboards exactly as they are.

That’s fine. This isn’t about winning. It’s about signaling that prevention counts, even if the machinery wasn’t built to see it.

Why it matters more than you think

Somewhere on your team is a quiet expert. The person who sees failure modes before everyone else. The one who redesigns something small and invisible and in doing so prevents the thing that would have kept ten people up at night.

If that person watches enough firefighters get promoted while their own work disappears into silence, they’ll leave. Or they’ll stop doing the prevention work that makes everything easier and start chasing visible chaos instead. Humans adapt to incentives. Even the wise ones.

You can’t rewrite the entire org. You can’t force people to value what they can’t see. But you can slow the decay. You can make sure at least one corner of the building knows the difference between foresight and adrenaline.

That’s not revolution. It’s maintenance of values. The unglamorous kind.

The small victory that still matters

When you make prevention visible, when you insist that quiet excellence counts, you’re not trying to save the whole system. You’re modeling a different one.

Maybe the org never changes. Maybe your best people still leave. But they’ll leave knowing what it feels like to work somewhere that recognizes the difference between stability and luck. They’ll know what to build when they get the chance. They’ll know what to defend when the incentives turn against them.

That’s not a grand win. It’s not a fix.
It’s choosing to lead with your values when outcomes won’t cooperate.

And sometimes that’s the only real power you get, and the one that ends up mattering the most.

The Ratio

2025-11-16T00:00:00+00:00

You raised some real money. Now you can finally hire people who've actually done this before.

The engineer who built infrastructure at scale. The sales leader with zero to $50M on their resume. The award-winning designer. The product person who shipped hits at two unicorns. The marketing exec with a proven playbook.

These people will boost efficiency. Solve the hard problems. Ship faster.

You hire five of them. If each one is truly 10x better than average, simple math says you should get 50x output. That's the theory anyway. Even if you're conservative and they're only 3x better, you should get 15x.

Six months later you're getting maybe 12x. On a good week, 30x.

Where did the other 20x go?

Nobody tells you this when you're hiring. But there's a tax. An invisible one. And it's expensive.

Tax One: The Speed Paradox

Someone on your team ships in a weekend what takes everyone else a month. That person is fast. Really fast. You hired them because of that speed.

Then you realize nobody else can touch what they built.

The project works perfectly. Solves the problem. Clean implementation. But it's a black box. The rest of the team can't modify it. Can't debug it. Can't extend it. Only one person knows how it works.

You just turned speed into a bottleneck.

The handoff attempt. Three-hour meeting to explain a two-hour build. The person receiving it still doesn't get it. They'll ping on Slack. Ask follow-up questions. Schedule another meeting. The speed advantage evaporated in the knowledge transfer.

Fast people skip steps. They don't document. They don't explain their reasoning. They assume context that others don't have. They're three steps ahead while everyone else is still processing step one.

This works when they're working alone. It breaks when they're working with others.

Now multiply this by five. Five people building things only they understand. Five sets of dependencies only they can resolve. Five bottlenecks disguised as productivity.

Worse, you keep picking them for every important project. They're the only ones who can ship fast, so they're the only ones you trust with deadlines. The rest of the team handles maintenance and bug fixes while the fast people take on everything critical.

Now the fast people are overloaded. They're context-switching between projects. They're the bottleneck on five different workstreams. And nobody else is learning the systems because they never get to touch the important work.

The team splits. Fast people on one side doing everything that matters. Everyone else on the other side waiting for the fast people to have time. Nobody's actually fast anymore.

You hire more people to help. They ramp slowly because the systems are sophisticated and the documentation is sparse. The fast people are too busy to explain things properly. The knowledge stays siloed.

Individual speed creates system slowness. That's the paradox.

Tax Two: The Impact Conflict

You probably have a performance review process. People asked for a process and you delivered. And that process almost certainly weights impact heavily. Show the hard problem you solved. Demonstrate the revenue you drove. Prove the thing you built that moved the needle.

This makes sense for evaluating individuals. It creates a problem when you put five high performers in a room.

Everyone needs impact for their next promotion. Needs to point to the thing they drove. They're competing for the same finite set of important problems. Some probably left their last company because all the high-impact work went to someone else. Or they spent six months debating whether a button should be on the left or right.

So the meeting isn't just about what's the right decision. It's about whose solution wins. Whose judgment was correct. Who gets one more item for their brag document. Doesn't happen in every meeting, but it happens.

Nobody says this out loud. But everyone feels it. One person's pushing for technical soundness. Another for user impact. Another for speed to market. All valid. All competing.

They're not being difficult. They're optimizing for what gets rewarded.

This is slow. Much slower than a team where one person decides and everyone else executes.

High performers need visible wins. When you have five of them, they're competing for those wins whether they realize it or not.

That competition shows up everywhere. Including how they approach problems.

Tax Three: Framework Collision

High performers have frameworks. That's how they got good. They've seen the pattern before. They know what worked at the last company. They have a mental model for how these problems get solved.

One framework per team works fine. Five frameworks per team creates a different problem.

The database debate takes three days. One person's framework says build for scale from day one. They've lived through the painful migration. Another person's framework says ship fast and migrate later. They've seen companies over-engineer for growth that never came. Both frameworks are based on real scars. Both people are trying to help you avoid mistakes they've already made.

The ICP debate takes a week. Go deep in one vertical versus serve multiple industries versus follow the revenue. One person's framework says vertical specialization builds expertise and referrals. Another says diversification reduces risk. A third says customer-fit matters more than industry. All three have worked. At different companies. In different contexts. For different markets. Which one applies here? The meeting becomes a comparison of past experiences instead of an evaluation of current reality.

They're not debating the decision. They're debating which past is most relevant to this future.

The infrastructure engineer has patterns from scale. The product person has frameworks from consumer apps. The sales leader has playbooks from enterprise deals. Each toolkit is good. Each one has been proven right. None of them are obviously wrong.

That's the problem. You don't have one way forward. You have five ways forward. And you spend your time deciding which framework to follow instead of just following one.

Five frameworks means you need someone to pick one. Except nobody can. Or rather, nobody can without telling four other high performers their judgment doesn't count. That's the real problem.

Tax Four: The Decider Problem

There's always someone in the room who makes the call. On a normal team, it's obvious who that person is. The senior engineer decides the architecture. The sales director decides the pricing. The person with the most context makes the decision and everyone else executes.

High performers are used to being that person.

They didn't become high performers by deferring. They got here by having good judgment. By being right when it mattered. By seeing the path forward and taking it. That's the skill that got developed. That's what got rewarded.

Now you have five of them in a room. Five people who are used to making the call. Five people whose judgment has been validated by results. Five people who aren't wired to defer.

Nobody wants to override the others. That means telling four people their judgment doesn't matter this time. Nobody wants to defer. That means admitting someone else's judgment is better than yours.

So you seek consensus. Can't pick one person's approach without dismissing the others. Can't ask people to defer when they're all equally senior. The only option is to find something everyone can live with.

Not because you value collaboration. Because it's the only way forward without someone losing.

Here's what this looks like. Product strategy meeting. Five people. Four different approaches on the table. Each one has merit. Each person can articulate why their approach is right and the others are risky.

One person could just decide. But which one? They're all senior. They all have track records. There's no obvious decider.

So you gather more data. Schedule a follow-up. Try to find an approach that works for everyone. Three meetings later you have a decision that's acceptable to all five people and optimal for none of them.

A team with one expert and four people who trust that expert decides in an hour. A team with five experts decides in a week. Same decision. Different cost.

This isn't ego. It's structural. You hired people whose judgment has been proven right. Then you asked them to sit in rooms with other people whose judgment has also been proven right. And you expected them to defer to each other.

They can't. That's not the skill that made them successful.

And while all this is happening, something else breaks down.

Tax Five: The Boring Work Gap

High performers got high-performing by solving hard problems. That's the skill that got developed. That's what got rewarded. That's what led to promotion.

Take a complex problem, go deep, figure it out. Build the thing nobody else could build. Close the deal nobody else could close. Design the experience nobody else thought of. Ship the feature that moved the metric.

Now you have five people who all want to solve the hard problem.

Except you don't have five hard problems. You have maybe two. And a bunch of boring work that nobody wants to do.

Who's updating the roadmap? Who's making sure the three parallel workstreams don't conflict? Who's writing the runbook? Who's doing the stakeholder communication? Who's managing the cross-functional dependencies?

Not the high performers. They're competing for the two interesting problems.

The boring work either doesn't happen or it becomes a resentment tax. Someone does it but they're frustrated because it's not what they were hired for. It's not what they're good at. It's not what gets them promoted. They're a staff engineer writing documentation. They're a principal designer doing redlines. They're overqualified and underutilized.

Or it doesn't happen and things slowly break. Miscommunication. Misalignment. Duplicated work. Conflicting decisions made in parallel.

The high performers are fighting over the two interesting problems. The boring work that makes those solutions actually work together is missing. And nobody wants to do it because it won't get them to the next level.

You end up hiring program managers and chiefs of staff just to do the coordination that nobody else will touch. That's expensive overhead for a structural problem.

Five taxes. Five ways the math breaks down. The overhead is invisible when you're hiring. You're thinking about what each person can do. Not what happens when they all try to do it together.

The Tipping Point

You hired five high performers for a team of five. The overhead hurts, but you're still getting 30x output. Better than average.

Now change the ratio.

Three staff engineers on a team of four. Five principal engineers on a team of six. A leadership team that's all VPs with no directors or managers.

Research on team performance found the optimal mix is around 25% high performers and 75% average performers. Beyond that ratio, too many stars on one team turns their positive impact negative.

You're not paying 20x overhead anymore. You're paying 60x. Maybe 80x. The taxes compound because there's nobody left to absorb them. Nobody to defer. Nobody to do the boring work. Nobody to build the simple version. Nobody to just make the call.

When high performers become the majority, the overhead becomes the work.

This is when companies hire "glue people" just to make the team functional. Program managers. Chiefs of staff. Engineering managers who don't code. People whose entire job is coordination because the high performers won't do it.

That's not scale. That's a broken ratio.

What This Means

Hire great people. They're valuable. One high performer on a team of average people is a force multiplier. Two working together is still good.

Three is where it gets complicated. Five is where the overhead eats your returns.

This isn't about ego or personality conflicts. It's structural. Put multiple people who are used to being right in the same system and they create friction. High performance characteristics that work individually don't combine the way you think.

The taxes are real. The speed paradox. Impact conflict. Framework collision. The decider problem. The boring work gap. They exist whether you believe the math or not.

You can pay these taxes. Sometimes it's worth it. The 30x you get from five high performers beats the 5x you'd get from five average people. But you're paying 20x in overhead for that difference.

That's the deal.

Nobody tells you this when you're hiring. You're thinking about talent density and capability and what these people can do. Not thinking about the ratio. Not about what happens when they're all in the same room trying to work together.

The research says 25% high performers, 75% average. That ratio exists for a reason.

Now you know.

The Safety Of Busyness

2025-10-30T00:00:00+00:00

Your manager asks what you accomplished in the last quarter. You start listing things. Helped ship three features. Stayed late and unblocked two projects and fixed countless bugs.

She nods. Then asks, "But what did you solve?".

You stop and think. You realize you don't have an answer.

You've been around a lot of building. You've supported it, kept it moving. But you haven't solved a hard problem or pushed a new idea forward. And you didn't notice until someone asked.

The Choice You Keep Making

Monday morning. You open your laptop planning to finally dig into that auth system redesign. The one that's been bothering you for months. The one where you know the current approach is wrong but fixing it means three days of thinking and another week of convincing people.

Slack lights up. Someone needs help with the build. You help. Another message. Question about the API you wrote last year. You answer. A meeting invite for this afternoon. You accept.

By lunch you've been helpful to six people and haven't touched the auth system. Tomorrow, you tell yourself. Tomorrow you'll have time. You've been telling yourself that for three weeks.

But you are also kind of relieved.

You're relieved you didn't have to open that blank document and stare at it. Relieved you didn't have to expose what you don't know. Relieved you could spend the day doing things you're already good at instead of things that might prove you're not as capable as everyone thinks.

The requests are real. The interruptions are real. But so is the quiet comfort of letting them fill your day. One yes at a time, you're choosing safety over growth. And you're calling it being helpful.

Why You Keep Choosing Safety

You know this is happening. You feel the weight of unsolved problems in the back of your mind. That auth system. The flaky builds. The performance issue nobody wants to touch. So why don't you just do the work?

Sitting down to do it makes you feel stupid.

You open the auth system file. Start tracing backwards. Fifteen minutes in you have ten files open and you've forgotten where you started. The next file is two thousand lines written by someone who left the company two years ago. The comments are sparse. The variable names made sense to someone, but not to you.

An hour in, John pings. Bug in production. You jump on it. Relief washes over you. You get to stop feeling stupid and do something you know how to handle.

Proposing something real makes you vulnerable.

You spend three days on that refactoring proposal. Six months of work, mapped out. You pitch it to your team. They probe your thinking. Push back on the approach. That's what they're there for. But every question feels like evidence you missed something obvious.

You don't fight for it. Better to let it die in the meeting than defend something that might be wrong.

Failure would prove something you don't want to know.

What if you push that proposal through and three months into implementation you discover you missed something fundamental? What if the whole thing crumbles? Better to have a small failure now that nobody notices than a big public one later.

What if you're not as capable as you think you are? That's the real question. And you'd rather not answer it.

Success creates pressure you're not sure you can sustain.

If your proposal works, you need to see it through. The actual implementation. The migration plan. Months of work that come after. And if you succeed, the expectations change. Can you keep delivering at this level? What if this was your one good idea?

Safer to stay where you are, doing work that doesn't raise the bar.

What You're Really Trading Away

Every week you spend answering the same questions is a week you're not building new capabilities. Every day you patch instead of fix is a day you're staying exactly as capable as you were yesterday. You're not learning. You're not growing. You're running in place and calling it progress.

But the cost is deeper than that. You're trading away your sense of yourself as someone who solves hard problems.

Two years ago you would have jumped at that auth system redesign. You would have been excited by the challenge. Now you avoid it. Not because you're busier. You're more afraid. Afraid of not being as sharp as you used to be. Afraid that if you actually tried, you'd discover you're just average.

So you stay busy. You rack up replies in Slack. You show up to every meeting. And slowly, quietly, you become someone whose main skill is being available.

Then you notice newer engineers tackling problems you've been avoiding. Because they haven't learned yet that being helpful is safer than being wrong.

The Work of Facing It

So how do you actually stop choosing safety? Not with calendar blocks or productivity hacks. With harder work than that.

You have to sit with the discomfort.

Thursday afternoon. Architecture review. You're about to pitch that auth redesign. The one you've been thinking about for weeks but only actually worked on for six hours total because you kept finding reasons not to.

You have slides. Sort of. Three diagrams that explain the new approach. But there's a gap in slide four you couldn't figure out how to solve. You thought about it for an hour yesterday and got nowhere. So you left it vague.

You could cancel this meeting. Say you need another week. Nobody would question it. Your hand moves toward the calendar. You stop.

You start the presentation.

Slide one goes fine. The problem statement. Everyone nods. They know the current system is broken. Slide two, your proposed fix. A few questions but nothing hard. You're feeling okay. Maybe this won't be bad.

Slide three. Someone asks how one part of the system works. You explain it. They push back. Point out a potential problem. You thought about this. You have an answer. They nod.

You're feeling better now. You can do this.

Slide four. The part you don't understand yet. You put up the diagram. You explain what you know. Then you hit the gap. You could bullshit here. Make something up that sounds reasonable. Nobody would know.

Instead you say, "I don't know how to handle that part yet".

The room gets quiet. Not a bad quiet. Just quiet. Mike speaks up with a suggestion. You hadn't thought of that. You say so. "I hadn't thought of that. Would that cause other problems?". Now you're having a conversation. Not defending a complete idea. Working through an incomplete one.

Ten minutes later you have three potential approaches. None of them are yours. All of them are better than what you walked in with.

This is what it looks like. Not having all the answers. Saying "I don't know" in a room full of people. Letting your incomplete idea get better through exposure. The discomfort of that moment when you said "I don't know how to handle that part yet" was real. You felt it in your chest.

But you didn't die. The idea didn't die. It got better.

You have to expose what you don't know.

Ask the questions that make you look stupid. "Wait, why do we do it this way?". "I don't understand this part of the system". "Can you explain the decision behind this?".

Every question feels like evidence of inadequacy. But it's actually learning. The engineers who grow fastest aren't the ones who already know everything. They're the ones willing to look dumb in the short term to understand something real.

You have to defend ideas before they're perfect.

Pitch the half-formed proposal. The redesign that still has gaps. The fix you're only 70% sure about. Put it in front of people knowing they'll find problems. Let them poke holes. Learn from what breaks.

You're not protecting quality by waiting until you're certain. You're protecting yourself from feedback. The work gets better through exposure, not isolation.

You have to accept that you might fail.

Sometimes you'll dig into a problem for three days and realize your approach is wrong. Sometimes you'll propose something that gets shot down. Sometimes you'll try and discover you're not as far ahead as you thought.

That's not evidence of inadequacy. That's what growth looks like. The engineers who solve hard problems aren't the ones who never fail. They're the ones willing to be wrong in public.

The Question That Matters

Tomorrow the messages will start again. The requests won't stop. You'll respond, help your team, stay busy. That's part of the job.

But that auth system is still broken. The performance issue is still there. You know it. You feel it.

You have two choices. Keep choosing comfort and slowly become someone whose main skill is being available. Or face the discomfort and become someone who solves things that matter.

So what did you solve last week?

Show Them The Kitchen

2025-10-19T00:00:00+00:00

Rachel left after less than a year. It wasn't her fault.

She joined a growing company as a senior leader with a track record of building teams and delivering results. The company had momentum. The team was shipping. Leadership seemed aligned.

Her first week was two orientation meetings and one product walkthrough. Standard stuff. Then came her first real assignment, a strategic initiative that cut across the organization. She asked for context. What had been tried before? Who were the key stakeholders? What were the political landmines? What were the pitfalls to avoid?

She got vague answers. "Just dive in and see what you find". "The team will help you figure it out". "We hired you because you can handle ambiguity".

So she dove in. She spent hours piecing together information from Slack threads and old documents. She scheduled meetings to understand team dynamics and power structures. She made assumptions, tested them, course-corrected when they were wrong. She figured it out because that's what capable people do.

Meanwhile, her manager focused on the small stuff. The format of her status updates. The structure of her project plans. Whether she was using the right template for her presentations. Detailed feedback on execution, zero guidance on strategy.

When Rachel asked why the CFO seemed skeptical about the initiative, she got a shrug. When she asked about the technical decisions that seemed odd, she was told "that's just how we do things here". When she asked about team dynamics that felt tense, she was told not to worry about it.

Her manager probably didn't set out to make Rachel's job harder. They were likely overwhelmed themselves, unsure how to translate their messy understanding of organizational politics into useful guidance. It's easier to review a status update than to explain why the CFO's skepticism isn't really about this project. It's easier to check presentation formatting than to articulate the unwritten rules about how decisions actually get made.

So they focused on what felt concrete. What they knew how to do. And they hoped Rachel would figure out the rest, the way they had figured it out years ago. What they didn't realize was that every shrug, every "you'll understand eventually", was teaching Rachel something. Not resilience. Not independence. Just that her manager didn't trust her with the information she needed.

A few months in, Rachel was delivering. The initiative was moving forward. Leadership seemed pleased. But Rachel was exhausted. Not from the work itself but from navigating blindfolded. Every decision required detective work. Every interaction required guessing at unspoken rules.

A few months later, she gave her three months notice.

Maybe you've been Rachel. Maybe you've been her manager. Maybe you've been both.

If you've been Rachel, you remember the exhaustion and the feeling that everyone else knows something you don't. The slow realization that your manager isn't protecting you from complexity, they're just not trusting you with information.

If you've been the manager, you remember the moment someone asked for real context and you deflected. You remember why. It wasn't cruelty. It was easier to talk about typos than to admit you don't fully understand the politics yourself. Easier to say "figure it out" than to reveal how messy and uncertain everything actually is. Easier to test their resilience than to risk them questioning whether this project should even exist.

Both sides feel justified. Both sides are exhausting. And the pattern continues.

Rachel was an experienced leader, but this pattern plays out at every level. Leaders withhold context and then wonder why people struggle. But there is a way.

The Two Kitchens

If you hire a chef, you don't need to show them how to chop an onion or make a sauce. They already know that. You do need to show them where the knives are. Which ones actually cut. Which burner runs hotter than the rest. Which cutting board has a crack that will catch the blade. Where the floor is slippery.

Some managers hand you the keys and say "figure it out". They think this tests your capability. They think withholding context builds resilience. They think if you're truly talented, you'll figure out the landscape on your own.

Other managers walk you through the kitchen on day one. Here's where things are. Here's what works and what doesn't. Here's the history you need to understand why things are the way they are. Here's the context that will help you make good decisions.

Both chefs can cook. One will be tired and resentful. The other will be effective and engaged.

The difference isn't the chef. It's the environment you created.

What They're Missing

Context isn't about systems or tools. You can read the documentation for that. Context is about people, patterns, and the unwritten rules that shape how work actually gets done.

The peer who pushes back hard in meetings isn't being difficult. They watched two projects fail because people were too polite to surface problems early. Now they question assumptions aggressively. When you know that, you can work with them effectively instead of taking it personally.

The project everyone's working on was supposed to ship last quarter. Scope tripled quietly, no one pushed back, and now everyone's stressed and working overtime to hit the new deadline. Without knowing that history, you just see a burnt-out team. With it, you understand why morale is low and can adjust your approach.

Last month the platform went down during a critical demo. Leadership is still jumpy about it, which is why almost every bug in production makes everyone feel like the sky is falling. Know that, and you frame your proposals differently from day one.

These aren't minor details. These are the things that determine whether your work succeeds or fails. And when leaders withhold them, they're not testing you. They're just making your job harder for no reason.

So if context is the key to success, why do we fail to provide it?

Why Smart Leaders Fail at This

Most leaders don't do this maliciously. They do it for reasons that feel logical in the moment but produce terrible outcomes.

They think you'll figure it out. They did. They learned the hard way, navigating politics and landmines until they built their mental map. If they could do it, you can too. This sounds reasonable until you realize it wastes months of someone's time and burns goodwill. The new hire who proposes the exact project that failed last year doesn't look strategic. They look uninformed. You just made them look uninformed.

They think withholding context builds character. Some version of "I don't want to hand-hold" or "let's see how they handle ambiguity". This isn't leadership development. This is hazing. You're not teaching people to navigate complexity. You're teaching them that you don't trust them with information.

They don't know how to guide. Most managers got promoted for execution, not for teaching. They can tell when a status update is formatted wrong. They can't articulate the strategic context that would help you write a better one. So they default to what they know. Control the details. Hope you figure out the rest.

They're protecting themselves. If you understand the full context, you might question their decisions. You might see that the strategy isn't as solid as it seems. You might realize the project is doomed and push back. Better to keep you focused on execution and insulated from the messy reality.

The organization makes it hard. In larger companies, information becomes political currency. Teams hoard context because it gives them leverage. Leaders can't share what they don't know, and the people with context aren't always the people doing the managing. The systems fragment information across silos and nobody takes responsibility for connecting the dots.

None of these reasons justify leaving people in the dark. But they explain why this pattern is so common.

Every Shrug Is a Choice

Think about the last time someone on your team asked for context. Not technical details, but the real context. Why is leadership skeptical? What's the history here? Who do I need to know about?

What did you give them?

If you're honest, you might have given them a version of what Rachel's manager gave her. A shrug. A "figure it out". A redirect to focus on something more concrete. Not because you wanted to make their job harder. But because explaining the messy reality felt harder than just fixing their status update.

Point out the wobbly table. Flag the slippery floor. Tell them about the knives that are dull and can hurt them. Show them which burner runs too hot. Not gossip. Not drama. Just the information they need to do good work.

Your experienced people are making decisions in partial darkness too. They've gotten better at guessing, but they're still missing context you could give them.

When you share context, capable people don't just survive. They thrive. They make better decisions. They move faster. They feel trusted instead of tested. And they stick around because they're not exhausted from navigating blindfolded.

Tomorrow someone will ask you for context. The CFO's concerns. The political dynamics. The history that matters.

You'll have a choice. Give them a shrug, or show them the kitchen.

The craft is theirs. The environment is yours.

You Don't Have To Like Jack

2025-09-30T00:00:00+00:00

Jack is one of the brightest engineers on the team. He delivers when others can't. He goes the extra mile. Other engineers look up to him and executives seem to love him. There's just one problem... You don't like Jack.

And it really doesn't matter why.

Here is the truth. As a manager you will spend time with people you don't really click with beyond simple work interactions. These people could be peers, but these people could also be humans that you are responsible for. You are their manager. Your work isn't to like them, and for that matter they don't need to like you either. Your work is to help them do their best work while being respectful. Yes, you need to click with someone, be able to make a joke, go out for a beer, and in the best case scenario meet some people you consider friends after a while. This is not the end goal though. This is a random happy accident.

But Jack's case is not the happy accident kind.

Your first instinct is to distance yourself from Jack and maybe delegate communication to other people. Then your 1:1s become a bit stiffer and if you have too much work, you prefer to reschedule, which you never do as a rule, or finish the 1:1 earlier for too many times in a row.

But that's just you protecting yourself, not doing your job. Your job is to show up anyway.

Unless you're a master of leadership from day one, you are going to make these mistakes, repeat them, and then figure out what really is going on. Let's try to save you some time and bad weekends.

The Work

Admit it. In order to understand and address something, you need to acknowledge it. You need to stop pretending it doesn't exist or completely ignoring it.

Maybe it happened slowly, with one comment or interaction, or maybe it was immediate. It doesn't matter. You are human. You are not a bad manager because you don't really click with someone. You might be a bad manager though if this is affecting your decisions.

So, admit it. Write it down in your notes. Maybe speak with your manager if you are comfortable with that, or share it with a trusted peer. Don't let it sit unaddressed.

Separate personal feelings from professional reality. Your feelings are valid. But your feelings are also irrelevant to Jack's growth in the company or getting the feedback he needs to move forward.

Your job isn't to manage people you like. Your job is to manage people.

That separation is a muscle you build. Every time you catch yourself making a decision based on how you feel about Jack and not his work, course correct. The more you do it the better you become. If the answer to "Would I do it differently if it was a different person?" is a yes, then you probably know what to do.

Build systems that don't care about feelings. Create the schedule and stick to your 1:1s. Document the discussions, ideas, and decisions. When time comes for that promotion for Jack, Helen, or Emily, you will have clear data and a framework to support any one of them and also your decision.

Systems are proof of fairness. Documentation is your defense against your own bias.

This might take time to organize, but it is time well spent.

Look past your irritation. Jack is a great engineer and you know it. But when you're annoyed by someone, your brain collects evidence to support that annoyance. You miss things. The quality of his work. His influence on the team. The ways he makes everyone around him better.

This isn't about forcing yourself to like Jack. This is about seeing Jack clearly. You need to actively disrupt that pattern. It won't make you magically like Jack better, but you will be able to navigate through your bias and see his value more clearly.

Reflect on your triggers. This is the difficult and awkward step. Why don't you like Jack? Really. Dig deeper.

Is it about some quirk he has? Is he disrespectful to people, condescending, or creating a hostile environment? Or is it really about you? Is it about his communication style that is different than yours or his values? You might even like Jack but you might be intimidated by his confidence.

It can be anything really. Your triggers are yours to work through, not his to fix. The reports who trigger you the most are often showing you something you don't want to see about yourself. Maybe Jack is confident in areas where you feel insecure. Maybe he questions things you wish you had the courage to question. Maybe he reminds you of who you used to be before you learned to soften your edges. That's not his problem. That's yours.

This is the hardest step because it requires admitting that maybe, just maybe, you're part of the problem. But it's also the most important because those triggers don't just affect Jack. They affect every person you'll ever manage who shares similar traits and they affect you as a person.

Deliver fairness every day. You don't have to like everyone. But you ought to treat everyone fairly. This is a daily discipline, not a one time decision.

You're in the promotion discussion. You prepared three paragraphs for Sarah, two bullet points for Jack. Same level of work. Different level of effort from you. That's the moment you catch yourself and course correct.

This is where most managers fail. Not because they don't know what to do, but because consistency is exhausting. It's easier to let a meeting slide. To delay difficult feedback. To forget to mention Jack when a cool project comes up.

Show up to the 1:1. Give the feedback. Share the opportunities. Make the introduction. Write the performance review with the same care you'd give to your favorite report. Fight for Jack's promotion if he deserves it, even if the idea of working with him for another year makes you tired.

Your team watches how you treat everyone, not just them. When they see you managing Jack with the same consistency and respect you show everyone else, even when it's clear you don't naturally click, you're teaching them what leadership actually looks like.

And Jack notices too. He might not know you don't like him, or maybe he does, but he knows whether he gets fair treatment. He knows whether you show up for him.

When The Work Isn't Enough

Sometimes you do all of this. You admit the problem. You separate feelings from reality. You build systems. You find Jack's superpowers. You examine your triggers. You show up every single day.

And it still doesn't work.

Maybe the communication gap is too wide. Maybe your management style and Jack's needs are mismatched. Maybe you're both great at what you do, but together you're not making each other better.

The kindest thing you can do, sometimes, is to help Jack find a different team. Maybe with a manager whose style complements his.

But here's the critical part. You don't get to take this exit until you've done the work. All of it. You don't get to shuffle Jack to another team because he annoys you. You only get to make this call after you've genuinely tried, after you've examined your own bias, after you've delivered consistent fairness and it's still not working for either of you.

And if you do help Jack move on, you do it with the same care you'd show anyone else. Good reference. Clear communication. Support during the transition. Because even if you couldn't make it work together, Jack's career matters. His growth matters. His success matters.

The Truth About This Work

I know I've used "you" throughout this article. Truth is, it should be "I" or "we". I've been there. You've been there. We all go through this at some point. Hire people who think like us. Get comfortable with certain personalities. It's human nature. It's also a trap.

The good news is you can get out of it. The important thing is to try. You might fail. You might only partly succeed. But trying is the difference between a manager who lets bias run the show and one who fights it every day.

Exits, Entries, and the Background Check in Between

2025-09-14T00:00:00+00:00

I've done this dance enough times now to spot the pattern. Forms asking for exact dates from years back, hunting for documents you swore you saved somewhere, that familiar anxiety when your work history looks messier on paper than it felt living through it.

Background checks aren't terrifying, but they can feel impersonal and awkward. There's no hiring manager to explain things to, no coffee chat where you can add context. Just you, some third-party service, and a checklist they need to work through.

I remember my first time years ago and how stressed I felt. Now I know the truth, that most of that stress was unnecessary. These checks aren't personal investigations, they're verification processes. But knowing that doesn't make them feel less invasive when you're in the middle of one.

So here's what I wish someone had told me before my first background check, and what I'm telling you now.

Exit Matters

Background check anxiety can start before you even apply for the new job. It starts with how you leave your current one.

Every burned bridge becomes a reference you can't use. Every loose thread becomes something a background check might snag on.

The rule is simple, don't be a d*ck. Not only because it's the right thing to do, but because your reputation follows you in ways you won't realize until years later. When a background check service calls your old company, you want the person who answers to remember you fondly or at least neutrally.

Finish your work or document it clearly. If you wouldn't want to inherit someone else's half-finished mess, don't leave one behind.

Share your contact info. Five minutes of exchanging phone numbers can prevent weeks of "we couldn't reach anyone to verify your employment" emails later.

Here is the thing, if you're managing someone who's leaving, the same rules apply. Don't make it weird. Don't sulk. Someone choosing to leave isn't a personal rejection. It's a career decision. Help them exit cleanly, and they'll remember it.

What These Checks Actually Are (And Aren't)

Background checks feel personal, but they're not. The company running your check is processing hundreds of applications weekly. They're not investigating your character. They're confirming your claims.

They'll verify:

Employment dates and job titles
Education and certifications
Sometimes criminal records or credit history
Maybe a quick scan of public social media

(Note: This applies to standard employment background checks. Security clearances and certain government positions involve much more intensive investigations that can include character references, financial deep-dives, and interviews with associates.)

They won't call your old boss to ask if you were "a team player" or "good under pressure". That's what reference checks are for, which happen separately and with your permission.

The uncomfortable part is how faceless it all feels. You can't explain that the company restructured twice while you were there, changing your official title three times. You can't clarify that you worked remotely from another country for six months, which might look weird on paper.

These services don't know your story's context. They just know what the paperwork says.

But here's what matters: they're not making hiring decisions. They're just gathering facts for the employer, who will interpret those facts knowing they hired you already. A small discrepancy in dates won't torpedo your offer unless it reveals outright deception.

Your Background Check Survival Kit

The secret to stress-free background checks is boring. Organization. Future-you will thank present-you for keeping things organized. Keep a folder, digital or physical, with these documents:

Offer letters and contracts from every job
ID or passport scans (high quality, readable)
Promotion letters or title change notifications
A few recent pay stubs from each employer
Resignation letters or termination documentation
Certificates from training, courses, or professional development
Contact information for someone in HR from each company (if possible)

This isn't about being paranoid, it's about being prepared. When you're scrambling to find a three-year-old offer letter at 11 PM, you'll thank yourself for this folder. This will be your "career packet".

Also, make sure your LinkedIn matches reality. Same company names, same job titles, same approximate dates. It's not the end of the world if there are small differences, but why create questions you don't need to answer?

The Long Game

After your second or third background check, assembling these documents becomes routine. What once felt like a month of anxiety becomes a week of straightforward paperwork.

Small hiccups will happen. Titles that don't match exactly. Forgotten certificates. Companies that got acquired and changed their HR systems. These rarely derail anything, they just require a quick email to clarify.

The real insight is this. Background checks aren't about you personally. They're about the paper trail you've left behind. The better you manage that trail throughout your career, through clean exits, organized records and professional relationships, the easier these processes become.

Your future self will thank you for taking this seriously now. Not because background checks are scary, but because they don't have to be stressful at all.

Why Engineering Work Isn't Done Until It's Actually Done

2025-08-30T00:00:00+00:00

I can picture myself in a team meeting or a 1:1, bringing this up - and yes, I’m spoiling the article a bit - "Asking someone to review your work isn’t a favor. It’s part of the job. It’s literally in their job description".

If I had a dollar for every apologetic follow-up I’ve read (or written myself) that starts with "Sorry to bother you… 😅" and asks for something be be unblocked, well, let’s not exaggerate. I wouldn’t be rich, but I’d be in a better financial state.

Sure, it has to do with everyone’s confidence and experience, and the environment and culture. But there’s also something broken in how we think about our work.

Our industry has a tendency to celebrate lone - but productive - wolves, the superstars, the sole engineer who stayed up until 2 a.m. to deliver a "mission critical" feature. Sounds good, but in practice, we’ve tried that before, and it didn’t work the way we hoped. We just produced burned-out people. Rich, maybe, but burned-out. Modern software development is collaborative, and it should be.

Asking for a PR review a second time? That’s not nagging, that’s about making sure of quality and also ownership. And just to be clear if there’s one thing to keep from this piece, it’s that the work doesn’t end when you move your task to the “Merged” column. It ends when it’s in production, and making sure everything works in production too.

When Politeness (or Confidence) Becomes Self-Sabotage

Why do engineers find the collaborative parts of their job challenging, especially when they need to ask for something to be done?

First, it’s human nature. Most of us find it difficult to be "that person" who asks three times for a review, the next iteration of a design, or specs that never came with a ticket. We don't want to stop people doing their "more important" work. And let’s not forget about introverts!

But there’s something deeper. Many engineers, especially early in their careers, see their work as done when they move a ticket from "Started" to "Review." Usually, a senior engineer or manager will step in, but too often, no one explains that we all contribute to the team’s success, not just with code.

I’ve seen projects delayed because hesitation accumulated over time. Nobody got hurt, and the company didn’t fail, but it’s a shame to lose a milestone after hard work, just because someone didn’t follow up.

What "Done" Actually Means (Spoiler: It’s Not What You Might Think)

Let’s be honest. Engineering or implementation work is usually only 50–60% of the total effort. When you click "Create PR" and add reviewers, the work isn’t done. It’s really just a draft waiting for review, either code-wise or as an end-to-end experience.

There could be one minor comment, a major issue, or even a complete misinterpretation of the specs that needs rewriting that can get the team off of their plans by significant time. It all depends on the case.

So yes, our work isn’t done when we create the PR. It’s done when it’s in production, and the system hasn’t crashed. I once had a very experienced engineer on my team who, with every release, would open a new tab to check, “Did we bring down the app? Nope. So far so good.” After all these years, that habit still sticks and I still crack a smile every once in a while when thinking about it.

But back to following up on work that isn’t visible. Let’s call our engineer Anna. She got specs for a new feature, estimated her work, implemented it, and wrote solid tests. She moved her ticket to “Review” after self-testing and creating a PR, and added a reviewer. The next day, she mentioned in standup that she’d start the next ticket while waiting for feedback.

Her PR sat untouched for five days because she only mentioned it once. When she finally followed up, the reviewer was busy with something urgent. Between UI changes and code revisions, the feature took an extra week and a half. Yes, Anna did amazing work, and yes, someone else could have raised their hand earlier, but the milestone failed simply because she didn’t follow up.

The Professional Follow-Up Playbook

Here’s the good news: this is a learnable skill. The secret is replacing apologetic uncertainty with confident ownership.

Timing matters, but not the usual way. For normal reviews, 24–48 hours is reasonable. For blockers, same day follow up is expected without being aggressive. Critical issues? Most of the team should already be on top of it.

Context is everything. Compare these approaches:

“Hey, can you please review my PR when you have some time?” (ambiguous, easy to ignore, priority unclear, it will most probably be at the bottom of the tasks)
“@specificmembersoftheteam Could you please review the payment integration in PR #847 by Thursday? It’s needed for the client demo we discussed.” (specific, deadline-driven, business context)

One gets lost in the noise. The other gets action.

Make it stupidly easy for reviewers. Write PR descriptions explaining not just what changed, but why. Add self-review comments highlighting areas where you want specific feedback. Include screenshots for UI changes. Provide context. Your reviewer probably has multiple PRs to handle - like you probably do - so removing ambiguity about urgency is crucial.

Follow up, especially if it’s a repeat request: "I need a review on PR #847 by EOD Friday to hit our sprint commitments. Can someone take a look, or should I find another reviewer?" This isn’t confrontational, it's trying to figure out a solution.

Stop apologizing for doing your job. Replace "Sorry to bother you again…" with "Following up on…" You’re not bothering anyone. Treat this like any other impediment in delivering your work. Because it is.

Building a Culture That Actually Works

Now, if for some reason you ended up on the leadership side, then this is for you. Many things can go wrong, but leadership sets the tone. Encourage the team to remember that success is a group effort, not individual heroism.

It can start in a 1:1 by setting expectations about accountability and ownership. In standups, a simple question like "Who will handle the review?" or a gentle nudge to prioritize reviews can create healthy habits over time.

If I’m working with a team and notice a lot of WIP in the review column, I explicitly ask them to prioritize it for the day rather than jumping into new work. It works, but you need to understand the board and the remaining tasks.

Processes and habits matter too. Set guidelines like time limits for reviews or limits on how many tickets can be reviewed at once. Leadership must model responsiveness, urge collaboration, and create safety so people aren’t afraid to remove impediments and own their work.

The Real Work

Finishing the code is the the first part. More work comes afterward, the follow-ups, the reviews, the small nudges that make sure what you built actually reaches production. Done is not a task moving across a board. It is the moment when your code quietly works for real people, without anyone needing to check if it broke.

Engineering is rarely a solo act. It is more like a relay, where every handoff matters, and those nudges are just part of keeping the baton moving. When the team finds that rhythm, the process feels almost invisible, but when it is missing, you notice immediately. That is the subtle work that makes engineering truly done, not just finished.

The Complexity Paradox: Why Fixing Windows Got Harder When Everything Got Better

2025-08-15T00:00:00+00:00

Windows machines. The gift and the curse of this world. And for the record, I've been using Macs for the past ten years, so what follows might just be a Windows problem or... who knows.

My experience goes from Windows 95 up to Windows 7, and apart from some hiccups here and there (yes Vista, I'm looking at you), some driver issues, and some early development tools that could take two to three days to get working, I had good feelings toward the operating system. After Windows 7, I lost touch a bit, and I always need some time to rewire my brain and work with the OS again.

But maybe that's part of the problem. Or maybe it's something deeper about how we've traded simplicity for sophistication.

When Machines Decide to Have Opinions

There were two and a half cases that really made me question the nature of modern computing. Each one a perfect example of how our "improved" systems have become their own worst enemies.

Case One(and a half): The TPM Tantrum

One laptop decided, seemingly overnight, that it would return a cryptic TPM error demanding a full reset. Fine, we thought. Reset completed, problem solved. Two months later, the same machine had the audacity to reboot mid-email, trapping itself in an endless repair console loop with messages claiming it "couldn't repair Windows."

This time, even a reset wouldn't work. We had to download a specific manufacturer version of Windows, rebuild everything from scratch, and do it all while on the phone with a support team that was as mystified as we were. They had no real understanding of what had gone sideways and just asked to send them the laptop for fixing. We did it ourselves, of course.

Case Two: The Sleepy Reboots

Another PC started randomly rebooting when waking from sleep. No warning, no pattern, no apparent reason. The logs pointed to the ever unhelpful "Error 41," which, for the uninitiated, is Windows-speak for "Kernel-Power failure." It's a generic "your system shut down unexpectedly" notice that could mean anything from a bad driver to a failing power supply to a cosmic ray flipping a bit in RAM. In plain English, it's Windows shrugging and saying, "Something happened." Still no fix. The machine works fine until it doesn't, which is somehow worse than a failure you can count on.

Do They Make Them Like They Used To?

A few weeks earlier, I joked about the old days when you had a problem with your machine. You either had a "tech" person (usually someone's cousin who "knew computers") who would most probably format your PC, or you would do it yourself. The nuclear option was the only option and you also had to cancel everything for the weekend. You had a lot of work to do!

If you saw a BSOD (Blue Screen of Death), you didn't have a lot of choices. You would either format everything and start fresh-and everything would magically work again-or you'd throw the machine out and get a new one. If you had no money, then you had no PC. It was brutal but honest.

The beauty of this approach wasn't the destruction-it was the clarity. One problem, one solution. Your computer either worked or it didn't.

The Infinite Complexity Machine

Nowadays, you have all the information at your disposal. You have more knowledge than ever before, and it's all accessible. But you also have a billion freaking things that could go wrong, each with its own rabbit hole of potential causes.

You get an Error 41? Well, it could be your power supply, your cables, the latest Windows update, the latest manufacturer update, a driver conflict, a memory issue, overheating, a dying hard drive, corrupted system files, or-and I'm only half joking here, the butterfly that decided to flap its wings in Osaka at precisely the wrong moment.

It's paradoxically more confusing than it used to be, despite having access to vastly more information. We've traded the brutal simplicity of "format and pray" for the infinite complexity of "debug and despair."

The Update Treadmill

You could blame the constant stream of updates. The 4 billion patches, security fixes, feature additions, and "improvements" that flow through our machines like a new create startup releases that never stops. Each update is a potential point of failure, a new way for things to break that worked perfectly yesterday.

Or maybe it's the hardware itself, designed now for replaceability rather than reliability. Components that used to last a decade are now expected to be swapped out every few years. Everything is modular, upgradeable, and somehow more fragile.

The Paradox of Progress

Here's the thing that really gets me: we've made computers incredibly powerful and capable, but somehow less dependable. A modern laptop can run AI models (look at me, keeping up with the times!), process 4K video, and connect to a dozen devices simultaneously, but it can't consistently wake up from sleep without having an existential crisis. It stirs for a few seconds, decides it’s not in the mood, goes back to sleep, repeats three times and then reboots!

We've gained infinite possibilities and lost the simple certainty that our tools will work when we need them. It's like trading a reliable hammer for a Swiss Army knife that sometimes forgets how to be a screwdriver.

The old way was harsh but honest. The new way is sophisticated but maddening. I'm not sure which I prefer, but I know which one lets me actually get work done.

The Real Question

Maybe the issue isn't Windows at all. Maybe it's that we've built systems so complex that no single person - not the user, not the support tech, not even the original programmers - truly understands how all the pieces fit together anymore.

We've created machines that are smarter than ever but somehow less predictable than a coin flip. And we've convinced ourselves this is progress.

The question isn't whether they make them like they used to. The question is: when did "better" stop meaning "more reliable"? Although if I'm being honest, I haven't had this kind of issue with the overrated and overpriced Mac laptops...

Moved to Eleventy After Ten Years With Jekyll

2025-08-02T00:00:00+00:00

Based on the git log, it’s been about six or seven months since I moved this blog over to Eleventy. I did take notes at the time and even started drafting a post about it, but then life happened. Things shifted, priorities changed, and that early draft is probably lost for good now.

So instead, I’m writing this from memory. I’ll try to cover what I did and why, though I can only recall one specific citation. The rest? Let's make some assumptions. 😄

For years, this blog was powered by Jekyll, using GitHub Pages - all provided by the good people of Github - which meant I could push to the main branch and the whole thing would build and deploy on its own.

Setup details, more or less:

Jekyll handled Sass preprocessing from some very old CSS files I wrote at the start of this blog.
There was also some magic JavaScript bundling, cobbled together from a guide I created nine years ago and never touched it again.
It all just worked, until it didn’t.

The Reason for Change

Jekyll itself wasn’t the problem. I liked it. Still do. But Ruby on a Mac can be a headache, especially when you don’t live in that ecosystem.

My old Mac? Jekyll ran fine. Why? No idea. Some mix of good luck and forgotten installs. But when I tried to get it running on a new machine, everything broke. I believe the last time I tried, I didn't manage to make it work even after a few hours, and I do like things simple.

I wanted a setup that didn't argue with me. It was time for a change!

The Plan

I knew I had to solve a few things quickly:

Find a Jekyll alternative that could preserve my URL structure.
Migrate all existing posts and templates.
Set up a build pipeline to deploy automatically through GitHub Pages.
Do it fast. If it took more than an afternoon or two, I'd probably abandon it and never come back. I had done something similar in the past, but as soon as I managed to make something work I lost my interest.

The Candidates

I started with Next.js. I'd been messing with it recently, so it felt like a natural first option. I got most of the migration done before realizing it was overkill. Too many moving parts. The URLs didn't work as I wanted. Everything felt heavier than it needed to be, especially for a blog.

So I looked elsewhere. Enter Eleventy.

I’d had my eye on 11ty for a while but never used it seriously. One of the downsides of Eleventy is the documentation. At that time at least, it was more of a reference than documentation, so it was... okay. But there were enough blog posts and migration guides to piece things together and don't get me wrong, the people at 11ty are trying their best.

Now that I'm thinking about it, why wasn't I using ChatGPT during all this?

After a one or two afternoons of reading and tinkering during a weekend, the blog was up and running again at least locally!

Eleventy Configuration

Most of Eleventy’s logic lives in eleventy.config.js. You can break things out more if you want, and structure it as any JS library, but this setup was enough for me. I also added two config files in, _posts and _data.

Here’s where I defined the preprocessing behavior, added collections, and plugged in a few filters. For CSS, I went with PostCSS and some basic plugins:

eleventyConfig.on("eleventy.before", async () => {
  const cssSourceFile = "./assets/css/index.css";
  const cssDestinationFile = "./_site/index.css";

  fs.readFile(cssSourceFile, (err, css) => {
    postcss([postcssImport, postNested, autoprefixer, cssnano])
      .process(css, { from: cssSourceFile, to: cssDestinationFile })
      .then((result) => {
        console.log("Writing CSS to _site");
        fs.writeFile(cssDestinationFile, result.css, () => true);
      });
  });

  eleventyConfig.addWatchTarget("./assets/css/");
});

For collections, I added one for posts and another for categories:

eleventyConfig.addCollection("posts", (collectionApi) => {
  return collectionApi.getFilteredByGlob(["_posts/*"]).reverse();
});

eleventyConfig.addCollection("postsByCategory", (collectionApi) => {
  const posts = collectionApi.getFilteredByGlob(["_posts/*"]).reverse();
  const categoriesMap = {};

  posts.forEach((post) => {
    const categories = post.data.categories || [];
    categories.forEach((category) => {
      if (!categoriesMap[category]) {
        categoriesMap[category] = [];
      }
      categoriesMap[category].push(post);
    });
  });

  return Object.entries(categoriesMap).map(([category, posts]) => ({
    category,
    posts,
  }));
});

To replicate Jekyll’s excerpt filter, I added this:

eleventyConfig.addLiquidFilter("excerpt", function (input) {
  if (!input) return "";
  const separator = "</p>";
  return input
    .split(separator)[0]
    .replace(/<script.*?<\/script>/gs, "")
    .replace(/<!--.*?-->/gs, "")
    .replace(/<style.*?<\/style>/gs, "")
    .replace(/<.*?>/gs, "");
});

You can check this file on Github of course for all the contents!

As mentioned, I also added:

site.js for shared variables.
_posts.json to keep paths consistent with Jekyll.

Non-Mandatory Updates

During the migration process I made some other updates that really simplified things:

Removed all old JS build steps and ended up with just seven dependencies. Five are for CSS. Two are Eleventy itself.
Simplified the CSS setup. Sass was overkill. I switched to native CSS variables, kept nesting via PostCSS, and stuck with BEM. Everything stayed in separate files, which keeps me happy.

No big flashy features here, but it felt good to clean house. Small dopamine dose!

The Build Pipeline

Once the blog was working locally, I needed a way to deploy it.

Of course I looked for something that Github Actions would help. There were a bunch of solutions that used a secret or something like that which I tried to avoid.

Somewhere along the way, I found actions/upload-pages-artifact. I can’t remember where, maybe GitHub Docs, maybe a blog post. Either way, it did the trick.

One more thing, because the repo is used for Github Pages and we are creating our own build pipeline, we need to inform Github about this. I added an empty .nojekyll file to skip their automation and let my build handle everything.

Final Thoughts

It’s been months since I finished this migration the beggining of this year. I’ve barely touched the setup since and things seems to be working even in a machine that I just installed it. That’s a good thing. No... That's a very good thing. Initial goal is done!

It runs. It builds. It deploys.

If it holds together for another ten years like Jekyll did, I’ll call that a success.

And one last thing: I still think Jekyll is great. It served me well for a long time. My move away from it was more about my limited Ruby skills and a desire for a simpler experience than any fault in the tool itself.

My suggestion would be to give it a try and see if it works for you. The team has done some amazing work. All the contributors, they’ve built something solid and lasting.

Assumed Citations

https://kittygiraudel.com/2020/11/30/from-jekyll-to-11ty/
https://24ways.org/2018/turn-jekyll-up-to-eleventy/
https://alex.pearwin.com/2020/06/jekyll-to-eleventy/
https://github.com/11ty/eleventy/discussions/1455
Dozens more, probably. It was a very productive weekend.

Check-in III

2024-02-02T00:00:00+00:00

As we step into February, we're faced with a blank canvas for the next thirty days. However, let's reflect on January first.

January was a bit peculiar, both in a positive and challenging way.

First of all, I had fewer working days and more days to relax, due to some PTO days I had from the previous year. Family issues threw me off my game a bit, yet simultaneously, I had to be super focused on tackling my to-do list before the month's end.

Why was I in such a rush? Well, after seven years in Transifex, I decided it was time to make use of my one month sabbatical perk. A sabbatical is always a great opportunity to relax, travel, do a personal project or just stop thinking about work. February might sound like a weird choice, but if I'm being honest, there is never an optimal time for a month-long break from work, so here I am.

I purposely didn’t plan anything for this month. If I manage to enjoy this time, clear my head and get ready to come back with more ideas, I will be happy. There are some things I want to do at home, which I have been procrastinating, but the main focus will probably be to make the best of this time even if it is a “anything can happen” month! More on that in four weeks!

Quantified (?) Metrics

Reading

Since the end of November, I've been on a break, so there are no major updates regarding my reading. I have spent some time delving into AI world updates. What can I say, I’m the adventurous type of person.

Writing

We have one for this month. A small update regarding work, breaks and exercise and how I’m experimenting with ways of getting midday boosts!

Trying Out New Things

It's better than nothing, but I should stop hoarding drafts at some point! This marks the fourth time I'm writing something titled 'Check-in III'.

Oh! Almost forgot. During a fairly not so good day, I started writing a mystery/crime short story about… who knows what it really is about, but I enjoyed the process so far and it is one of the pieces I’ve felt confident about the storytelling and the writing.

And since we are still in the Writing section, Michael Lopp started a new newsletter{:target="_blank"} that shares three writing prompts each Monday. It's nice to see people with some influence urging people to write. The “Writing teaches you how you think” quote couldn’t be more close to the truth!

Watching

Now that I’m thinking of it, I realise this category is proportionally opposite to the Reading section. We’ve been watching a lot of tv-shows and movies in our free time.

If I had to choose something, it would probably be The West Wing. A show that first aired in 1999, so 25 years ago!

In case I haven’t mentioned that in the past, I love Sorkin’s writing. Yes, his dialogue can be challenging, even for native speakers, and his themes are US-specific, and yes there are moments of cheesy scenes, but I’ve enjoyed most of his work and it’s the only show of his I haven’t watched yet. Have I told you how much I loved The Newsroom?

Exercising

I’ve written more about my routine this week, what I can share more is that for January I’ve done 16 workouts and I’ve managed to hit my steps goal for 19 days. Keep in mind that the goals are dynamic, and increase based on performance so at some point I cannot keep up. I could always change it to fixed, but where is the fun in that?

My current goal, though, is to incorporate more intensive workout minutes throughout the week.

I wish I had more specific numbers regarding exercising, but I'm still trying to figure things out in the "activity tracking" area and make sure I'm not getting duplicate tracking or something like that.

***

As I dive into this month with no set plans, here's to the unexpected, the unscripted, and the unfiltered moments. 🍻

Trying Out New Things

2024-01-28T00:00:00+00:00

January is ending and I already started experimenting a bit to work on this year’s themes, and more specifically on the physical and mental health area. How?

This week, I began taking a 15-20 minute break in the middle of my working day and spent that time on the treadmill with 3 minutes of running and 1 minute rest intervals. I usually manage to cover approximately a 1.5km distance.

So far, this routine has had various positive side effects on my day.

Doing My Exercise

After injuring my knee (nothing serious but annoying), I became scared of going into a week of recovery and physiotherapy sessions again. As a result, I reduced my exercise and had to start from scratch again.

Twenty minutes per day of intervals seems to be a good pace for now. It's challenging enough for me, but it doesn't create any issues.

Until I start increasing this time again, it means I can do this exercise during my day as a break from work, which is one more side effect.

Taking a Break

I must admit I struggle with taking breaks during my working hours. Even though I manage to maintain a work/life balance with a lot on my plate, breaks are something I find challenging. And even when I do take a break, I can't seem to forget about the work I'm leaving behind.

However, this changed. I close notifications, do some stretching, blast some music in my ears, push start and the treadmill and I can forget about everything for the next few minutes.

Getting a Boost

Oh yes... the endorphins! Or maybe it's just a placebo. I don't know, but it works!

Some weekdays are challenging. I might find myself not fully energized during a meeting or a specific task in the midday, and I don't like it. Until now, I haven't found something that truly worked, but over the past week, I've been getting a lot of energy after doing the 15-minute workout.

Not Another Fitness Buff

You might be wondering, "Why is this guy preaching about exercise?"

Well, I'm not. I will probably be the last person on Earth to do that. But I found a way to help me feel a bit better throughout my day. If I find an alternative way that doesn't require any effort, I'll probably prefer it.

So, if I had to leave you with a few things, it would be:

Please take some breaks.
Move a bit during these breaks.
Find something to do that takes your mind off work and energizes you.

Twenty Twenty-Three Review

2024-01-02T00:00:00+00:00

End of the year 2023, an opportunity to take a look at the highlights.

It was an interesting year, sometimes a mojo rollercoaster, but productive!

As always, work is a big part of my life. Apart from a three week break during the summer I can’t remember a week that wasn’t interesting and challenging at the same time at a technical or managerial level. I still haven’t found a way to stop thinking about work in the evenings!

2023 started with me getting into managing a new team with all the bells and whistles that come with it. Building rapport, trying and tweaking things, until it works out for everyone. There never is an immediate outcome, but when it comes it’s the reason I’m doing this work.

Some more leadership changes happened through the year in the company that affected the usual flow of working, and after the first half I started on a journey of a new big project. As a rule, I try not to undertake big blocks of work so I can never block other team members. This was different. Foundational work, core implementation, managing multiple teams and outcomes. I had my day to day usual work, but my focus was on bringing results on an implementation level. Again regardless of the challenges and the feeling of stretching too thin at times, but when I see the results, it makes me forget the difficult parts.

And of course working in an amazing talented team makes things easier!

On top of that, the AI domain is more approachable than ever to everyone, changing/improving everyday and people from all industries are hyped. It’s everywhere. Exciting and strange times!

2023 Goals Review

Flexible themes I set last year as focus points to motivate myself. Overall, not bad!

Reading 👌👌👌

Oh my, oh my! It’s been an amazing journey! I spent A LOT of my free time diving into a new book. Usually one after the other. I started slowing down in October/November but overall I read 24 books! Most of it were Stephen King novels, but it was what I needed at that time to make me fully immerse into something different than TV or work! I don’t believe I’ve read so many books in a year in my adult life before.

A special mention to one non fiction book I enjoyed this year and had some “book club” sessions with other engineering managers.

It’s Engineering Management for the Rest of Us{:target="_blank"} by Sarah Drasner. I am a bit biassed because most of the book aligns with my values on how to approach leadership. It was a great refresh and a must read for anyone that would like to take or has already taken the management path in their career.

Writing 👎

Ah… This is where the ball was dropped. Back in October 2022 I started a schedule of posts here or on LinkedIn and worked great, but in March I lost my motivation a bit. My mojo wasn’t there and I preferred doing something completely different. I think this had something to do about being tired of listening to my inner voice again and again. Hopefully this will come back this year.

Regardless, I did write seven articles, which for some of them I’m very proud of.

Extroversion 👌

No huge improvements, since priorities changed during the year, but there are continuous small step improvements that are happening daily.

Exercising 👌👌👌

This is a win! After some years I started improving my - non existing - exercise habits. I started with an old indoor bicycle we had here at home. It wasn’t bad and I almost exercised everyday without an issue, but I needed something different.

Back in August, we did invest in a treadmill, since I love jogging. Like most people, I overdid it and hurt a bit my knee, which needed some physiotherapy, but the doctor mentioned it wasn’t my fault since I must have had some kind of an issue since my teens and the treadmill just made it resurface. All is good on that front now. I’m having a healthy pace and by the way, my favourite music to run is at 165 BPMs.

I also got an activity tracker and it seems that most of the days I’m keeping up with my step goals. Regardless of the hiccups along the way, the addition of exercise and small changes in my eating habits helped me lose some weight. That weight loss is not that important, but the fact that my metabolism is still working fine is a good sign.

2024 Themes

I hope this year is going to be focused on Health. Physical or mental. It’s similar to this year’s theme, but I’ve been stretching myself too thin for some years and I’m close to 40. I’m feeling fine, but if I want to keep up for the following years, I need to be taking care of myself more.

Health.
Take up writing again.
Keep the same pace of reading and exercising.

The Bait, the Switch & the Loop

2023-03-16T00:00:00+00:00

The Bait

You find yourself on a call with three people on a Wednesday afternoon.

One is the hiring manager, one HR representative and another person they introduced as “Page, a member of one of our teams”. They all look tired, but you notice they are trying to smile. It’s evident that this is a routine call for them. It could have been the third or fourth similar call for the day, and it looked like this one was outside their usual working hours. Or not.

Sheila, the hiring manager, describes how the teams work and that there is always an opportunity to grow and experiment. She then starts talking a lot about herself, but you choose to ignore that for now because the offer in the initial stage was impressive. A 35% raise to what you are getting in your current gig. This will be an excellent boost to being closer to your wish list.

After the diversion, she talks about the teams again and their achievements. A relief. Your mind strategically blocked the previous discussion.

The HR representative lists some of the perks, the growth plan they have in place that is carefully tailored to each individual, and how every day is a chance to learn something new. He seems proud of the work and process they have in place. He gave some well-thought answers to your questions.

Page only speaks when you mention day-to-day work. She seems happy with the result overall, which is a good sign. She asks about previous experience and some easy technical questions. This isn’t supposed to be a technical interview, but you are happy to answer.

That last session comes to an end after one and a half hours. Something feels slightly off, but you’ve done your due diligence. Glassdoor reviews seem high and legit, and overall the company has a good reputation. You managed to talk to someone that was working three years ago in the company, and he didn’t have anything bad to say.

Based on this, it’s “go” time. The money is good, and you need a change. You have been looking for some time now, so you do it. You are excited and ready to join.

The Switch

Two months into the gig, you haven’t done a 1:1 yet and haven’t seen the people from the interview again. You heard that Page, the “member of one of our teams”, resigned. These things happen. The hiring manager is usually lost somewhere in a meeting, being busy.

Your peers are amazing at their job, but they are disoriented most of the time, like no one knows why they do the things they do, and the team’s last project didn’t make it to production because of “reasons”. Six months of design and implementation are out of the window. You have no idea about the next steps. Someone will tell you, but not knowing what is coming is not your strong suit.

That week, Thursday would be a “come to the office” day - remote wasn’t really remote - and mid-day, an angry person you haven’t seen before walked into the open office space and screamed, “Who pushed the ‘a4e9c’ commit? WHO DID THAT?!?”.

You had no idea who that person was, but who behaves like that in a professional environment, and how doesn’t he know he can check the contributor for the commit in the following line? Later you learn that this was the VP of Engineering…

Perks magically disappear, and bureaucracy and hidden agendas are a thing. Six months passed - during which similar not-so-good things happened - and you are on an interview call again. The team seems great, and there is no weird gut feeling this time. As a precautionary measure this time, you found two people on LinkedIn still working there to ask about the company. The money is not that good, but the whole thing seems more human-oriented.

Of course, you take the job.

The Loop

Bait and Switch it’s a known sales technique to get customers to buy in with low prices and then raise prices as you go towards the signing time or after you are bound with a contract. It’s used as a bad practice in UX, and It’s also used in interviews when an interviewee is not the person applying for work (who does that?!?).

This is different. This is the case of a company overselling to the candidate. Not small things about setting priorities or gym perks. I’m talking about significant differences in culture. The things that might differentiate a healthy from a toxic environment.

I used to wonder what is the purpose of hiding the truth in an interview?

Every new hire is an investment. If you hire someone and they leave after a few months, you have spent time and energy onboarding them, making them part of a team and training them. Don’t they get that if a candidate sees BS in the first months in the company, they will just bail out?

Then it hit me. They do know it.

Take 1

Once you are in, you are probably staying. Money and perks are the incentives. They depend on this being enough to retain people even if they are not completely happy. Even if a percentage of people leave, other people will stay.

Take 2

In big organizations in a growth state, hiring becomes a number in someone’s OKRs, “Hire 70 people”. This person might be so up the chain that it is probably too difficult to understand the actual situation in the organization. They do believe they have an amazing culture.

Take 3

Big organizations, big stakes. Current goals in someone’s OKRs are more important than anything else. Again, “Hire 70 people”. Every month they don’t hit this number, it translates to lost opportunities and lost revenue (crazy, right?), so they do anything to cover this number no matter what. If people leave, this can be a problem for another quarter, another person.

And this is the Loop. An endless Loop of new goals to cover the numbers of the previous goal. Every month, every quarter.

***

This might come up as criticizing, but it’s really not. I get it. I don’t like it, but I get it. And, of course, this doesn’t apply to all organizations. There are teams out there, even with hundreds of people, that maintain a fantastic culture in which people can thrive.

What is needed is extra caution. An interview is a two-way street. Ask questions so you can better understand what is going on. Reach out to people currently working there and make sure what you heard in the interview was legit. If you join, keep the organization accountable for their promises.

Be vigilant and keep an eye out for the Bait and Switch!

Check-in II

2023-03-03T00:00:00+00:00

February has been and gone in the blink of an eye!

I hate when time flies like that, and I can’t remember much. This is when I’m in the “busy” mode, losing a lot of “me” time.

On the good side of things, my other half got me a present that I’ve been thinking of buying myself for some time now. I’m usually hesitant to buy “one more gadget”, and I wasn’t sure if I would like the feeling of using it. So yeah, I got a new Kindle Paperwhite! Is it essential? No. Do I consider it overpriced? Yes, but they have done a fantastic job on the “reading a book” feel.

I replaced a laptop monitor without breaking things, which I consider a win. I’ve been using computers for the biggest part of my life, but I’m clumsy when it comes to fixing an electronic part that needs delicacy and patience. YouTube FTW, of course!

On the other hand, we did break the heatsink of an ancient computer we use to watch movies. Yes, it was a month of fixing - well, messing with probably is the best way to put it - computers.

The old beast was having some issues lately and rebooted at will due to high temperatures, so the next logical thing was to open it, clean it, remove the CPU heatsink, replace the thermal paste and assemble it again. Removing it was pretty easy, but when we tried to put everything back, something wasn’t right. And this was when we figured out we’d broken the awful heatsink mount pins that lock on the motherboard.

There is a message I would give to the person who created this patent… “You deserve a special place in hell!” Why would you make this kind of mechanism that is difficult to understand - if you haven’t broken one already - breaks easily, and everyone hates it?

If you ever do this similar work and see these kind of pins{:target="_blank"}, please have a spare heatsink in case something goes wrong.

Writing

Didn’t publish much this month. I just wasn’t in the mood for some reason. I felt “bad”, but then I thought about “The importance of being idle” and decided to not stress myself out.

I wrote some things, of course, but only one was published:

Six Years of Using Team O’Clock

Reading

Stephen King Corner

The Institute

Kids with Telekinetic or Telepathic powers are abducted and moved to a facility called the Institute. Excellent read. I enjoyed it. Mid-level King.

The Bazaar of Bad Dreams

A short story collection published in 2015. Great read. Grim, but great. Who doesn’t like a car that eats people?!?

Roadwork (as Richard Bachman)

A man spiralling into madness because his house (and his workplace) will be demolished to create an extension to a highway. I suggest this only if you have read all his other 60+ novels. Not his best work. My least favourite so far. I couldn’t relate to the main character or his motives, and the writing just wasn’t as good as usual. I should do a ranking of his novels at some point. Everybody else does it.

Prague Fatale - Phillip Kerr

I was sceptical about this, but the person at the bookstore told me, “Any of these stories are good. I’ve enjoyed them too. Just pick one!”.

This is part of a fourteen books series that focuses on a Berlin cop, Bernie Gunther.

This novel takes place in October 1941, and Bernie Gunther gets involved in a story with Reinhard Heydrich, Reichsprotector of Bohemia. Murder, spies, women and decadence.

If you enjoy reading mystery books with some historical figures, this one might be for you.

Watching

There was more watching this month. These are some things that stood out:

The Last Of Us - Great storytelling. There should be some more episodes or a faster pace.
Shrinking - I always enjoy this kind of comedy.
Prospect - While watching this movie, I was thinking about it in a written format. I would love to read it.

Six Years of Using Team O’Clock

2023-02-16T00:00:00+00:00

When I joined Transifex, the organization had - and still does - an Agile mentality in how they built the product and had been using Scrum for two or three years before my time.

Day 1

During the first team’s standup, I noticed a product the team used called Team O’clock{:target="_blank"} to help them with the ceremonies facilitation. It would be later on that I discovered that I was working with the founders on a daily basis.

We used it for standups at first (and maybe planpoker, but I might be wrong on the timeline), and it felt natural. A two-minute purple circle timer around each person’s avatar was responsible for keeping us within the two minutes limit to discuss what we did the previous day, what we would do that day and if we had any impediments. After someone was done, it would go to the next person based on a random order.

In my eyes, it was a simple and fantastic way to avoid awkward looks about who should go next or people speaking for too long and missing the purpose and the essence of a standup which is to coordinate and align.

Two Weeks In

At that point, we would still do retrospectives in a more traditional way in which the facilitator would have to gather notes - or note down everything if it was an open discussion - and keep and track action items. I’m not sure if you have done this, but after a while, it becomes cumbersome, especially if it is a Friday afternoon and you’ve been trying to finish up any sprint work leftovers. Retrospective is the most important ceremony of a team, but it shouldn’t be challenging to facilitate. All the participants should be focused on the value of the meeting and nothing else.

With great surprise, on a Friday that was no different from any other Friday, our Scrum Master sent us a link to join, and we saw a new feature called Retrospectives.

It had everything needed. You could choose from a number of predefined activities and had a notes-gathering step, a notes-grooming step, a voting step and a last discussion step. Everyone would write their own notes. The note-grooming could be a team effort, and of course, no bias because you wouldn’t see what other people voted for until the discussion step.

It was pure magic. All the annoying problems… gone, and everyone could enjoy the retrospective!

Evolution

A few years passed. Transifex changed, but so did Team O’clock. The product became from a simple standup tool to a full solution for agile ceremonies and team alignment. Our team even moved away from Scrum to our own agile framework{:target="_blank"}, and we were still covered by what the product offers. We missed nothing!

The purple circle timer became a straight line, and the product was redesigned at some point. Now asynchronous standups are possible. You have a time difference with your teammates? Solved.

We can create custom activities in retrospectives and have sentiment analysis and other useful metrics to understand a team’s state.

Hell, I’ve even managed to use the Retrospectives feature more than once for a twenty-plus group of people, with little work and a successful result!

Feature Requests

There are only two things I’m missing from TOC.

The first one is some music during the gathering notes step of a retrospective. I’ve made a feature request about this, but it falls into the “Won’t fix” category (I wonder why :P).

The second one is a recurring reminder in Slack about action items, which I can build by myself since there is a public API{:target="_blank"} I can use to create a simple integration to do this!

***

Yes, I’m very happy with the product and always excited about any new addition the team makes.

Having said that, it’s worth noting that I try not to get too attached to any service.

I have preferences, of course, but I should be able to work under any conditions. But, there are some cases of products that do solve a real problem, the product serves the user, not the opposite, and on top of that, you have a great user experience.

Team O’clock is one of those cases. Just trust me, and go give it a try{:target="_blank"}!

Check-In

2023-02-04T00:00:00+00:00

Hey! A check-in for January. What went well. What didn’t go well, and what I’ve been doing.

Work

New year, new challenges!

The start of a quarter is usually busier after a holiday break. A lot of people with time off - including me - are coming back and trying to kickstart things, getting into the zone again and returning to the usual flow. If you add the fact that it is the beginning of the year, yes too many things to tackle! A to-do list with items to be done always does the trick for me.

Overall, I can’t complain. Many things done, with good results! It was a good month.

Reading

Five books already. I know I won’t be able to keep up this pace, but I enjoyed every moment! I’ve also picked up Turn the Ship around (again) as an audiobook. Still in progress.

The Last House on Needless Street - Catriona Ward

“This is the story of a serial killer. A stolen child. Revenge. Death. And an ordinary house at the end of an ordinary street.”. This is the only thing I will say (copied/pasted, really) regarding the plot so as not to spoil anything. I read it in one sitting.

The Restaurant at the End of the Universe - Douglas Adams

I loved the HGTTG. I can’t remember the last time I laughed so much with a book. This one was "more difficult". Well not difficult, I still liked it, but for a 300 pages book, it took me a while to finish it. The constant action and scenery change probably had something to do with it. Not sure. It’s a good one either way!

I hope they paid good money to the people translating these series into other languages. This must have been a difficult job.

Stephen King Corner

Lisey’s Story

Lisey is Scott Landon’s widow. Scott was a successful writer. We see her life after his death, their life together and Scott’s life.

Slow start. Amazing storytelling. It’s impressive to see King in his 70s and, after all these books, still writing and writing good stories.

Misery

This is a classic. A writer (again) is kept captive by an unstable fan of his work.

I’ve yet to see the movie. This is a good one.

It

Mysterious disappearances, murders, and pure evil in the form of a clown. What else do you need?

I love Stephen King’s characters. They are flawed and somehow real, even when they are a bit over the top.

The greek version is two books with a total of 1700+ pages. Is it a beast to read? Yes. Are the surroundings sometimes too descriptive for my taste? Yes, but it’s fantastic.

A warning about this book though. There are some awkward scenes that may or not make sense and can make you unconfortable. Don't ignore this book because of it, if you haven't read it already.

Writing

I got three articles out there. One coding, one about Disqus and one about leadership. A good start!

On Leading Through Values

2023-01-21T00:00:00+00:00

Almost one year into the Engineering Manager role, I thought of providing more clarity to the team regarding what this role is about. What I did was to give a brief presentation about it, and there it was, a slide titled “What’s on my mind” (yeah, “kudos” on the great titles).

I’m not sure what I was trying to accomplish with it, but it was probably an effort to explain “What a manager does” at an individual, team and organizational level. In reality, it was a combination of values and responsibilities (who knows what 2019 Thanos was thinking).

Looking back, I see awkwardness and difficulty articulating my thoughts (slide title FTW again). The truth is, though, that some of these values are still values I live by - well, they’ve evolved, as we all do - and writing them down was equally beneficial to me as it might have been for the team. But why?

Why Have a Set of Values

Guidance. To know when you live by those or not - just as a company does - and cross-correct if needed. Especially in hard times, having your own values can guide you and get you out of a difficult place. Hiring, firing, promoting, saying the difficult thing, choosing the right battles, even staying in the company you work for, or leaving for another gig. You pick. Each and every day is full of decision making.

And why write them down? For one, If you write them down, it becomes real. And the other reason is to recognize dumb ideas before letting them out in the world.

Why Communicate Your Values

First and foremost, you are now accountable to more than yourself. No vague grey areas. “I’m accountable to you to do this, and you have every right to call me out if I’m full of BS”. Be cautious. This is a make or break situation.

As I mentioned, some of your values will change at some point, but as long as you are evolving and not bending the rules, everything will be fine!

Then I know it’s a bit obvious, but nobody can read your mind, and people don’t have the time to observe. They got things to do. Communicating your values gives them a better idea of your actions, and you might inspire your team to follow this practice.

In Retrospect

This has worked great for me so far, so what would I suggest to my past self before 2019?

Have a set of written values to guide you, especially during the most challenging times. They don’t have to be life-changing. Just do it.
Communicate your values early on with your team.

Disqus No More

2023-01-10T00:00:00+00:00

Back in 2015, I created - I'm still having difficulty calling it a blog for some reason - this place. GitHub Pages with Jekyll (free hosting FTW), the Poole theme with some CSS and layout changes, and there was a thing - my own thing, besides work - in the internet. "Introverts of the world, unite".

Depending on the mood I'm in, I make minor improvements here and there or remove parts I don't like.

So a few weeks ago, it was time for Disqusm, a commenting system, to be removed from codegazerants.

There were two main reasons for doing this:

Disqus has had a bad reputation for a long time now. Tracking, ads, JS bloat, loading times etc.
People don't comment that much so removing it won't do any harm.

Regardless of the last point, I wanted to keep the ability to comment on something. What if someone had a question?

Search for an Alternative

For a moment, I thought of creating a small custom service to handle the whole commenting system, but this has been done too many times in the past by other people. Maybe a weekend project at some point.

It was time for a Google search, and the only requirements were something that worked on a static site and was lightweight.

I saw webmention - maybe for another time - and then two similar approaches that looked good to me. The first one was utterances, and the second one was giscus.

Both are Github apps that use its features as a commenting system. The only reason I chose one over the other was that giscus - a newer app - is using comments instead of issues.

Enter giscus

The setup was straightforward. You install the app in Github for the specific repository, include a JS script in your page, and that's it.

You can also do some CSS tweaking, but I didn't bother. The default one looks nice on this site.

The only "issue" with the giscus (and utterances) approach is that only people with a Github account can interact with it, but it's something I can live with.

Old Comments and Moving Forward

I apologise a bit for removing some old comments, although I'm sure no one remembers.

I will try to keep giscus for some time, and if no one is using it, I will remove this too.

Create a New Jekyll Post with a Simple Shell Command

2023-01-01T00:00:00+00:00

Let's build a shell command to automate the creation of a new post in Jekyll.

This will be a short one.

Jekyll has its quirks, and I always wondered why they don't have a simple command to create a new post. I used to copy/paste the previous one, but you know how things are... If you can automate something boring in a few minutes, just do it.

Creating the Script

We first need to create a simple bash script to do the job for us.

So, create a new file. I call mine newjekyllpost.sh and add the following parts to it:

#!/bin/bash
filename=`date +%Y-%m-%d-new-post.md`

cat > $filename <<EOF
---
layout: post
title: A title
description: A description
categories: ["tag"]
social_image: add here
---
EOF

Let's rubberduck this.

The second line is a variable called filename. This will be used for our file name with today's date and the following format:

YYYY-MM-DD-new-post.md #

The third line will create the file with the contents we like. I chose to add the YAML front matter with the most used content for my posts. If I don't want something, I remove it.

And that's it. Our script is that simple. Let's now try to execute it.

Making the Script Executable

If you try to run it, you will get an error about permissions. There is one more step, which is to change the file's permissions.

chmod u+x ./newjekyllpost.sh

After that, running ./newjekyllpost.sh will create a file in the specific folder with our contents.

Adding an Alias

Let's do one more last thing to make our lives easier.

Right now, we have our script in a specific folder, so we need to write the path each time, which is also boring. Adding an alias for the script will work like magic.

Move the script to any path you want. I keep a scripts folder inside my Users folder.

Open the profile your shell is using. I'm using ZSH, so I have this line in my .zshrc file:

alias njp="~/scripts/newjekyllpost.sh"

Every time I run njp in a folder, the script creates a new file. You can choose any alias you want, of course.

Run source pathoftheprofilefile to reload the new changes, and we are done.

Improving the Script

As I was writing this, I though there is one more thing we could do to improve the script. If there are argguments to the script use them to postfix the filename.

So our first part of the script becomes:

if [ $# -gt 0 ]
then
  filename=`date +%Y-%m-%d-`
  filename+=`echo "$@" | sed -e 's/ /-/g'`.md
else
  filename=`date +%Y-%m-%d-new-post.md`
fi

In the "bash" language what that means is:

If I have arguments add the date in the filename. Then join with a space all the arguments as string with "$@" and then replace the spaces with - which is done by the sed part.

If I have no arguments, business as usual.

If we run njp this is my new post at 2022-12-30 the file will be create will have the following name:

2022-12-30-this-is-my-new-post.md

Just remember, all of this can be achieved with any language. The logic is the same. I just chose to do it in a bash script because, why not?

Twenty Twentytwo at a Glance

2022-12-22T00:00:00+00:00

Let's try something for the first time. Writing a few words about the whole year.

Overall, it was a busy, stressful but productive year. For some reason, I cannot remember a lot from the first half.

I'm going to focus on the more positive things!

On Writing & This Place

The second half of the year was more productive for me. I pushed myself to work on article ideas and post them on a "soft" schedule. I didn't want to do it as an obligation, but I needed something to get me out of my comfort zone.

I started being more active on LinkedIn and here. This one is the tenth post for this year in codegazerants, an improvement based on 2020 and 2021 post numbers. I'll take the win!

The weird thing is that I never stopped doing the work. I have a considerable number of drafts that were never published. Editing and publishing is always the most challenging part.

Some things that changed and helped me be more active:

I stopped worrying about expressing my thoughts more in public.
I accepted that I'm probably better at writing short content of 500 - 1200 words and not worrying about "big revelation" articles. (see also "on Reading")
It doesn't matter if I write about things others have written before. It's my perspective. If someone finds this information helpful, well, that's awesome!

I also did a micro-redesign of this place. I shouldn't even call it micro, but did I put some effort into it.

On Reading

This year I started reading books in a physical form again. I wanted to get my eyes off of screens and reduce binge-watching. Do something different.

I tried to read things that wouldn't be work-related. I had to remember again to focus on one thing and enjoy it. I started with a "goal" of reading two books, and in six months or so, I managed to go up to ten. The themes were mainly Fantasy, Mystery, and Sci-fi. Stephen King, Philip K. Dick, J.K Rowling and Douglas Adams were the writers I enjoyed reading.

Unfortunately, I didn't manage to finish reading Foucault's Pendulum once again. I stopped at page 400+ or something. Again. I probably need to accept that I'll never read the whole thing. Who knows.

Now an observation on work-related reading, I had an information overload at some point. I needed a break. I was mainly consuming instead of learning.

It was challenging for me to focus on a 4000 words article or 300 page book unless the writer had the charisma of storytelling. I respect and acknowledge the work and achievement of writing a book, but I've become a fan of reading things where writers quickly get to the point.

On Miscellaneous Things

I'm in year two of remote working, so it was time to create my own space in the house. An "office room" where I can focus on the working hours and when I'm not working use it to play some music. No more working from the kitchen or moving equipment around the house to get some "privacy".

On the subject of music, I got a new guitar{:target="_blank"} that I absolutely love and a keyboard that I can play a tune or two. Playing on an S-type guitar for a long time created a challenge for me to make a good sound on the Sheraton, but it's also like a white canvas for me. I am still trying to tame the sound of a semi-hollow guitar.

On 2023

Based on the last two years, I'm not sure I should be making big plans, so there are some things I want to continue doing:

Take up challenges that help my introverted self improve.
Keep reading and writing. It looks like ten was the magic number for me this year. Twenty sounds like fun.
I'd like to start doing some kind of exercise. I'm not a person that loves exercising, but it's needed.

As promised, 500-1200 words! 👌

On The Power Of Individuals

2022-12-09T00:00:00+00:00

High-performing teams are fascinating.

A team with the right values and a good flow in place moves a company forward. But it's never about speed. It's all about efficiency.

What happens, though, when day-to-day routine kicks in? Groups can get lost in their current goals and lose opportunities to make a difference. They lose the chance to see the impact of small initiatives in favour of day-to-day work that helps their primary goals.

At times, all that is needed is for an individual to raise their voice and a call to action.

"I believe this matters, and I need help".

A great team listens. A great team leans in. There is no need for roles, levels or permission. They just need a nudge from someone, and they will be there to solve a problem as a group. You are driving change with just a simple move.

High-performing teams are made of outstanding individuals.

Thoughts on Feedback

2022-10-15T00:00:00+00:00

Thoughts on feedback, the really short version.

Feedback is difficult and needs a lot of practice. Why? Because emotions are involved.

There are two parts to becoming better at it. The rules are simple, but it's hard to live by.

Receiving Feedback

To get feedback, you need to be and also look open to feedback. If your face changes and you start being defensive - even if you have counter arguments - when someone gets out of their way to give you some feedback, there is a chance they won't do it again. And yes, we've all been there.

Listen to what the other person has to say, even if you disagree.
Ask questions to understand more about the situation. Keep notes.
Thank the person for the feedback. They've given some thought, time and care about you.
Sleep on it.
Act if needed.

And yes, ask for direct feedback like hell! I usually mention to the people around me that even if their feedback "hurts" me, at the end of the day, if it's constructive, it will make me better. It's going to make me grow.

Giving Feedback

There is a strong possibility you have some feedback about people, but you are hesitant to share it because you are afraid of how the other person will feel and how it might make you look like not a good person.

Be empathetic, respectful and direct.
Try not to judge, but describe a situation and its effect.
Be precise and provide examples, don't be vague.

I'll let you in on a secret. Everything about providing feedback ends when you do it. After that, It's the other person's job to filter and evaluate the input. There is no need to convince or be convinced about anything.

You can't imagine how fulfilling it is to hear an honest "Thank you for pointing this out. I wasn't aware of that" after providing hard feedback.

One last note. I was lucky enough to be introduced to Radical Candor and SBI (Situation Behaviour Impact) model by Dimitris Glezos a few years ago, which helped me improve the way I use feedback. So it's my turn now to urge some people to give these resources a try if they haven't already.

This was originally posted on LinkedIn.

Chaos Engineering For Humans

2022-10-09T00:00:00+00:00

If you came here about Chaos Engineering for your services, “it’s not what it looks like”.

Chaos Engineering

You might think I just said it’s not about Chaos Engineering, but I’m about to give some kind of definition of Chaos Engineering. Yes, I am.

Our products have become, or maybe better say, have progressed to be, a sum of multiple services and not a monolith service that tries to do everything. Core application, auth service, user service, payments service, prospects service. Name your service here.

The whole system should be resilient.

Unit and end-to-end testing should be in place for each service, but these are done in a predictable way. What I mean by “predictable way” is that we provide a specific input and expect a specific output. And this is what we test.

Don’t get me wrong, this is a great state. But what would be the next step?

Here is where Chaos Engineering comes in. The essence is that you create a situation for your whole system, for example, latency or absence of a service. You observe what happens, and then you prioritize improvements.

This helps increase confidence, have a more predictable system and protect customers from a total failure of your system if your 10th service down the road underperforms.

Getting Closer to A Point

What is a team? A group of individuals that work together have an input (a goal), a throughput (their work, processes etc.) and an output (results).

A team is a system.

When all parts work, we have great results. When something is wrong with a part of the system, then the whole system starts to show signs of latency.

Do you see where I’m going with this?

Teams as Systems

This all began when I started thinking of what would happen if someone from my team left tomorrow or a new team was created, and we had to do an internal restructuring? What would happen if a manager had a sabbatical? What if someone was on medical leave for two weeks?

Would that absence block the team? What could we do to remove some uncertainty? Can we get some ideas from Chaos Engineering and apply them to a team?

The idea is to find a way to observe when limitations arise in a team and understand where we can optimize.

Here are some simple metrics you can have, but of course, it varies based on each organization:

Can the team groom a feature?
Can the team deploy a feature?
If specialization is missing, can the team find a way to bypass that?
Are the initial milestones on track?
Is team morale high?
What are the main areas the team struggled with?
Can the team self-organize and communicate with the stakeholders if leadership is absent?

The Organic Way

There is an easy and organic way to observe and draw some conclusions without changing anything in your team.

Try to observe when someone has Paid Time Off or, for some reason, cannot contribute to the problem at hand. Is there sufficient documentation? Do you have a bus factor one? Having one person less, will reduce the capacity of a team, but is it in the danger zone?

Note down the observations, share them with the team and create action items.

The More Creative Way

Create the circumstances that will create some “planned turbulence” for the team.

Once a quarter, throw all the team’s names in a randomizer, and the winner gets one or two weeks of having to work on a project they choose or join another team. During that time, they should not interact with the rest of the team.

There are no secrets or sketchy areas here. The team should know the goals and the metrics.

Final Notes

Please remember that this is not a way to calculate individual impact, create mayhem or stress your team. It’s one more tool to create the circumstances for a team to observe and improve. Low impact initiatives might also be a good start.

Keep your team in the loop if you want to try this out. If they don’t feel comfortable, abort.

I would consider this suitable for an environment with a great culture. You need safety and team maturity. This is a next-level approach. You wouldn’t try Chaos Engineering for your system if you didn’t have a good system in place first, would you?

And one last thing, in case this wasn’t clear. You can apply this to any kind of team, not just Engineering teams.

Happy experimenting!

The Five Minutes Talk

2022-09-05T00:00:00+00:00

It's a random Tuesday morning after the team's standup, and Josh just nodded and asked if you had five minutes to talk.

You know that look because you've been there a few times before so you take your notebook and a pen. It's going to be more than five minutes. Best case scenario, half an hour. Worst case... who knows.

For a few seconds, you are thinking about the new OKRs, the ad hoc report someone asked for, the next big thing and other initiatives you promised to drive or help this week. You think you have a lot on your plate, and for some reason, you are feeling a bit grumpy today because something is off at home. You are only human, after all. But everyone is busy, so you decide to shove these thoughts into a mental room and close the door for a bit.

Josh seems a bit stressed out. You can notice that from his body language. He may even have imagined how this could go. How the conversation would start, progress and probably some possible outcomes. It seems like he really needs to get something out of his chest.

While walking to the room, you try to think about Josh and his behaviour over the last few days. Was he a bit too quiet? Did he participate less than usual in decision-making? When was the last time he was on a vent? Did you do anything to resolve the situation? When was the last time you gave feedback to him?

You sit down and stop thinking about the reasons he asked you to discuss. It's time to listen.

Triaging

You know how this starts, and you are prepared for it. Usually with an awkward "Look... I wanted to talk to you about...".

Josh could be giving his resignation notice, asking for a raise, discussing something regarding the team or sharing something personal that doesn't have to do with work.

Good or bad, it doesn't really matter. The key here is to actively listen and not lose focus with other things in the back of your mind or solutions. This is Josh's time.

You listen carefully. You Gather all the information you need to assess the situation and remove assumptions. You repeat. Then you act if it's necessary.

The Twist

This is not about how to act in these situations. This is about something else.

The truth is that Josh knows that you are busy. But he also appreciates you getting out of your way to listen and help him regardless of your daily schedule. It probably wasn't a big deal the first time you did it, but now he knows you can make time for him, and the most important thing is that he knows he can depend on you. You will be there for him and the team no matter what.

These interactions might look like distractions from focus, but trust me, they are not. This is a crucial part of the job.

Everyone Is Busy, but a Leader Should Never Look Busy

Leadership is not only about big gestures and fireworks. It's about consistency. Doing the things needed daily, so your team has the things they need to thrive. Often this means getting out of your carefully scheduled day to support them.

I'm not going to lie. This isn't easy. It's messy, unpredictable and you need to make sense of all the noise and, on top of it, make it look easy. People are not going to stay with you forever in the company. That's a fact. But interactions like these could sometimes determine someone's future in the company and show the kind of leader you are.

The five minutes talk is a lie. In reality, it's a well-disguised opportunity for meaningful conversations and trust-building.

Use JavaScript to Navigate Through a Table And Other Elements

2022-08-18T00:00:00+00:00

The browser API has given us many tools to navigate through a webpage, and if done correctly, you will have a great result without the use of any Javascript.

In some case though, you might need to enhance some of the navigation experience. Usually, this is a challenge in an application environment, or more specifically, on some elements of the application. And here is when JavaScript comes in handy.

A Beautiful Table

If you are using Gmail, then you probably have seen that you can navigate between the mail list with your up and down arrow keys. Gmail uses a table, and I have no idea what they are doing under the hood, but let's see how we can accomplish this.

We will go through some sections of the code, but keep in mind that we can use this code for various HTML elements.

The Basics

Let's get the basic stuff out of the way. We will create an HTML file. Let's call it index.html. Yes, we will do everything in a single file, no bundlers or anything.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Use JavaScript to Navigate Through a Table And Other Elements</title>
  <style>
    .is-active {
      box-shadow: inset 0 -1px 0 0 rgb(0 0 0);
    }
  </style>
</head>
<body>
  <table id="mytable" tabindex="0">
    <tr>
      <td>One</td>
     </tr>
     <tr>
      <td>Two</td>
     </tr>
     <tr>
      <td>Three</td>
     </tr>
     <tr>
      <td>Four</td>
     </tr>
     <tr>
      <td>Five</td>
     </tr>
   </table>
  <script></script>
</body>
</html>

Here, we have a simple file with a table and a CSS part with one class to visualise a selected table row.

One small addition that makes the difference is the tabindex attribute so we can focus on our table.

The Key Navigation Backbone

Let's design our navigation function. What could be the main parts of it.

  <script>
    function navigateElement(elementID, itemsTagName, activeClass, scroller) {
      function handleKeyboard() { };
      function handleScroll() { }
    }
  </script>

We have one main function here called navigateElement - which I'm sure you can find a better name for it - that takes some parameters. We could have everything hardcoded, but you will probably reuse this in other elements in your application.

elementID: The element we are going to add our key capture event listener to and includes our list items. We need to have this in case we have more than one navigateElement instance.
itemsTagName: The element's tag name we will navigate through.
activeClass: The active class we mentioned in our CSS part.
scroller: The element that is responsible for our content overflow. More on that later. Secret sauce.

The handleKeyboard does what it promises. It will handle the navigation between items, and the handleScroll will be responsible for always having in our viewport the selected element. This simple design is all we need for now.

The Key Navigation Code

Right now, our page doesn't do anything. Let's add what we promised.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Use JavaScript to Navigate Through a Table And Other Elements</title>
  <style>
    .is-active {
      box-shadow: inset 0 -1px 0 0 rgb(0 0 0);
    }
  </style>
</head>
<body>
  <table id="mytable" tabindex="0">
    <tr>
      <td>One</td>
     </tr>
     <tr>
      <td>Two</td>
     </tr>
     <tr>
      <td>Three</td>
     </tr>
     <tr>
      <td>Four</td>
     </tr>
     <tr>
      <td>Five</td>
     </tr>
   </table>
  <script>
    function navigateElement(elementID, itemsTagName, activeClass, scroller) {
      const mainDOMElement = document.getElementById(elementID);
      const scrollElement = document.getElementById(scroller) || window;
      const items = mainDOMElement.querySelectorAll(itemsTagName);
      const itemsLength = items.length;
      let selection = -1;

      function handleKeyboard(e, which) {
        if (e) e.preventDefault();
        if (!e && !which) return;
        items.forEach(item => item.classList.remove(activeClass));
        const selectedIndex = which || e.which;
        switch (selectedIndex) {
          case 38:
            if (selection == 0) {
              selection = itemsLength - 1;
            } else {
              selection--;
            }
            handleScroll();
            break;
          case 40:
            if (selection == itemsLength - 1) {
              selection = 0;
            } else {
              selection++;
            }
            handleScroll();
            break;
          default:
            break;
        }
        items[selection].classList.add(activeClass);
      };
      function handleScroll() {
        const el = mainDOMElement.getElementsByClassName(activeClass);
        if (el.length) {
          el[0].scrollIntoView({
            block: "center",
            behavior: "smooth",
          });
        }
      }
      mainDOMElement.addEventListener('keydown', handleKeyboard);
      mainDOMElement.addEventListener("focus", () => {
        if (selection < 0) handleKeyboard(null, 40);
      });
    }

    navigateElement('mytable', 'tr', 'is-active');
  </script>
</body>
</html>

If you copy/paste this code in an HTML file, should work out of the box.

Focus on the element and navigate through your up and down arrow keys.

But let's rubberduck the script in sections.

function navigateElement(elementID, itemsTagName, activeClass, scroller) {
  const mainDOMElement = document.getElementById(elementID);
  const scrollElement = document.getElementById(scroller) || window;
  const items = mainDOMElement.querySelectorAll(itemsTagName);
  const itemsLength = items.length;
  let selection = -1;
...
};

Simple things, we initiate some variables based on our parameters and set a selection to -1, which means that nothing is selected. If scroller is not defined, we get the window as our element.

The navigation part

...
function handleKeyboard(e, which) {
  if (e) e.preventDefault();
  if (!e && !which) return;
  items.forEach(item => item.classList.remove(activeClass));
  const selectedIndex = which || e.which;
  switch (selectedIndex) {
    case 38:
      if (selection == 0) {
        selection = itemsLength - 1;
      } else {
        selection--;
      }
      handleScroll();
      break;
    case 40:
      if (selection == itemsLength - 1) {
        selection = 0;
      } else {
        selection++;
      }
      handleScroll();
      break;
    default:
      break;
  }
  items[selection].classList.add(activeClass);
};
...

For each event we capture, we prevent the default behaviour. This is used to avoid browser page or element scrolling, resulting in a weird user experience. We are going to handle it ourselves in handleScroll.

Our selected item is based on the event.which or just a programmatically given which we are utilising the first time someone is focusing the element. If both of these are not set, we just return.

We remove the active class from all the items, then we have some logic checking if we are going up or down, and we decide to increase or decrease the selected. We also cover the first/last item case, and we go to the appropriate position.

After we have the selected item, we apply the active class to it.

The Scrolling Part

Now let's explain a bit the scrolling part. This is one thing I see people forgetting when creating custom navigation in HTML elements.

function handleScroll() {
  const el = mainDOMElement.getElementsByClassName(activeClass);
  if (el.length) {
    el[0].scrollIntoView({
      block: "center",
      behavior: "smooth",
    });
  }
}

Each time we use our keys to navigate, two things can happen:

The browser will catch the key event and scroll any element that could be considered valid, like the screen scroll, for example, and not our element. This is the reason why we use preventDefault in our previous code.
Since the event is not bubbling up, there is no scrolling happening, and if the content exceeds the viewport, the user won't be able to see the selected item at some point.

This is why we use the fantastic scrollIntoView. Before this, we would try to calculate the scrolling position of the wrapper, the element height, offset, and things that sound boring. scrollIntoView will solve this, and this is why we are calling it with each key press.

Adding the Event Listeners

One more thing left. To add the listeners for the key event and choose the first item when the item is focused if no selection is set.

mainDOMElement.addEventListener('keydown', handleKeyboard);
mainDOMElement.addEventListener("focus", () => {
  if (selection < 0) handleKeyboard(null, 40);
});

We are all set.

Takeaways

These small snippers are cool the first time you bump into them. After that, it gets a bit boring. You will want to make a helper for it. With some more work, it could include logic for the state if you want to combine it with a frontend framework like React, Vue or anything like that. But this is the basic logic.

If I wasn't lazy, I could also add some checks and validations with some beautiful errors for the developer, but I'll leave this up to you.

Once again, please don't forget to use tab to focus on the table first.

Mike Seavers - From Manager to Director: Guide to Managing Managers

2022-08-15T00:00:00+00:00

This week I watched a Mike Seavers (Epic Games as VP of Online Development) interview dated February 2022 on the Coding Sans podcast channel.

His honesty and anecdotes during the entire episode are inspiring. If you are interested in making a transition from an Engineering Manager to a Director role, I would consider this a must watch{:target="_blank"} or read{:target="_blank"}.

The following excerpts of the podcast made me want to watch the whole episode.

On his initial motivations to get the director's role

My motivations weren’t right. My focus wasn’t to enable others or to become the best leader I could be. I wanted the bigger title, I wanted to feel important, and I was chasing my ego. Unfortunately, I think this is more common than people like to admit.

On his first mistake as a director

I was proud of what we managed to accomplish, but when it came time for performance reviews, I received the worst review of my career. My peers and everyone around me outside my team said in their feedback that they had no relationship with me. They didn’t know what I was doing, they just saw me making changes in engineering without involving the leaders of the project management team, the release management team, or the QA team.

On turning the ship around

I looked for patterns and themes in all feedback I received, and I poured myself into reading books, and taking classes to improve my leadership skills. I didn’t turn it around overnight, but I tried out new tools and learned new skills to become an effective director.

At the time, I didn’t have the skills necessary for managing managers. This was a failed transition for me. It took me about three years to figure out what a successful director looks like.

And this was just the beginning of the episode.

Mike shares more insights about other themes like necessary skills for this role, common mistakes, support to new directors and other interesting topics.

Overall, great interview and leadership content podcast. I'm not sure why there are not more subscribers to this channel.

If you are interested in this kind of content, I'd suggest checking out the other episodes too.

Jekyll: Goodbye ‘site.GH_ENV’

2022-08-07T00:00:00+00:00

This code has been a great friend for some time now. Based on git history, I added this six years ago and didn’t touch it again.


{% if site.GH_ENV == ‘gh_pages’ %}
    # Analytics code
{% endif %}

What this does, or better say what it should do, is to check if we are in a production environment - aka Github Pages - and print Google analytics code. Of course, I have no idea where I found this, but it stopped working two months ago.

A few days ago, I saw a warning in the Google Analytics console, a place I don’t hang out much. The message was Property codegazerants.com is not receiving hits.

I disregarded it at first, but then I thought it was worth checking out my code.

After doing some “view source” on production, I saw that there was no GA script. 🤷 My beautiful condition just stopped working.

I searched about the GH_ENV key and found two or three Github issues from 2014 and 2018, but that was it. Undocumented configuration. That’s the spirit!

Of course, as a responsible engineer, I then went through the proper channels (it’s called documentation) and found that the same thing could be achieved with


{% if jekyll.environment == 'production' %}
    # Analytics code
{% endif %}

What are the key takeaways here?

Using undocumented, internal parts of libraries, is a bad practice.

Especially in a work environment, that can result to money loss because someone changed their library.

It’s not worth it, trying to understand what went wrong six months from now.

See you again in 2028, dear configuration variable!

Articulating Company Values & Living Them Authentically by Jeff Lawson

2022-07-23T00:00:00+00:00

I really enjoyed watching Jeff Lawson's - CEO of Twilio - presentation about a company's values.

Whether you are doing your first professional steps in a start-up or you are a founder, you should check this one out. There are a lot of insights on how to create, revisit your company's values or even evaluate the values of the company you are a member of.

How to TitleCase Jekyll Titles With Node

2020-06-11T00:00:00+00:00

Back in December, I decided to refresh this place and start writing again. What I noticed then was that my post titles are a bit inconsistent. Some words are uppercase, some lowercase, some don't even bother, but you get the point.

I wanted to change these titles then, but let's be honest, sometimes I'm a bit lazy. So while I was sitting in my couch yesterday I thought of doing something about it.

I had two choices, doing it manually wasn't one of them. Install a dependency and get it done in two minutes or try to build something. I chose the latter because I didn't want to install any dependency. And that was the only rule, no dependencies.

It was a bit easy since I told my self that a) There was no shame in this, which means no tests no fear of judgement b) No need to freak out about details, just make it work and have some fun.

What Was Built

This is a simple node script that runs in the Jekyll blog root and will change the titles in the _posts folder. No more no less.

I started thinking of how I will tackle this and there were three parts:

Read the contents of the _posts folder.
Find and change the title based on some criteria.
Write the new content to the file.

Loop Through the `_posts` Folder

Simple stuff, we use Node's core libraries to:

Read the contents of a directory.
For each item of this directory, we read the contents of this item.

You could log your data in case you need to see the contents of a file. We just used some basic file-based operations.

const path = require('path');
const fs = require('fs');

const directoryPath = path.join(__dirname, '_posts');
// Loop through the folder's files
fs.readdir(directoryPath, (err, files) => {
  if (err) {
    return console.log('Unable to scan directory: ' + err);
  }
  // Loop through all files
  files.forEach((filename) => {
    const file = `${directoryPath}/${filename}`;
    fs.readFile(file, 'utf-8', (err, data) => {
      console.log(`go wild!`);
    });
  });
});

Find and Change the Title Based on Some Criteria

The fun part! All the code we are going to use is going to inside the readFile function.

We have three things we need to tackle:

Get the FrontMatter part.
Extract the title.
Split the title by spaces and check each word if it needs to be changed, also based on a list of small words that shouldn't be changed. We are going to do this with simple regular expressions and not a library. Remember, we are just hacking our way to result.

const path = require('path');
const fs = require('fs');

const directoryPath = path.join(__dirname, '_posts');
// Loop through the folder's files
fs.readdir(directoryPath, (err, files) => {
  if (err) {
    return console.log('Unable to scan directory: ' + err);
  }
  // Loop through all files
  files.forEach((filename) => {
    const file = `${directoryPath}/${filename}`;
    fs.readFile(file, 'utf-8', (err, data) => {

      // ======== NEW CODE FROM HERE =========

      // Split the content with `---`. The second key will be what we want
      const frontMatter = data.split('---');
      if (frontMatter) {
        // Parse the frontMatter and find the title
        const [originalTitle, uselessKey, title] = frontMatter[1].match(
          /(title:\s*)(.+)/im
        );
        // These words should not be capitalised
        const smallWords = /^(a|an|and|as|at|but|by|en|for|if|in|nor|of|on|or|per|the|to|v.?|vs.?|via)$/i;
        // Split the title by spaces
        let newTitle = title
          .split(' ')
          // Loop through all the items
          .map((item, index, array) => {
            if (
              // Does it belong to the smallwords
              item.search(smallWords) > -1 &&
              // and it's not first or last word
              index !== 0 &&
              index !== array.length - 1
            ) {
              // This needs to be lowercase
              return item.toLowerCase();
            } else {
              // Everything else should be capitalised
              return item.replace(/^['A-Za-z']/, (item) => item.toUpperCase());
            }
          })
          .join(' ');
          console.log(oldTitle, newTitle);
      }
    });
  });
});

Ok, you may think, a lot is going on here. If you run this, nothing is changed in your files, but you should see in your terminal a list of new and old titles.

What I'd like to explain is the two regular expressions we have here. The first one, /(title:\s*)(.+)/im :

Will try to find a match of title: some content.
We create two groups. The (title:\s*) will get the title: and any kind of white space after it.
The (.+) part will get the rest, in our example the some content.

If this regular expression finds a match this will produce an array of results which will be:

[
    'title: some content', // Full Match - originalTitle
    'title: ', // Group 1 - uselessKey
    'some content' // Group 2 - title
    ...
]

And that's why we named the second one uselessKey in our code since we are not going to use it. We only need the originalTitle and the title.

The second one is easier /^['A-Za-z']/

From a given string match the first character if it is in the range of A-Z or a-z.

I know it's a bit silly to explain it to this extent, but for a lot of people, regular expressions are a mystery.

Write the New Content to the File

We have one more small thing to do. Replace the title in the original file data and save the file.

const path = require('path');
const fs = require('fs');

const directoryPath = path.join(__dirname, '_posts');
// Loop through the folder's files
fs.readdir(directoryPath, (err, files) => {
  if (err) {
    return console.log('Unable to scan directory: ' + err);
  }
  // Loop through all files
  files.forEach((filename) => {
    const file = `${directoryPath}/${filename}`;
    fs.readFile(file, 'utf-8', (err, data) => {
      // Split the content with `---`. The second key will be what we want
      const frontMatter = data.split('---');
      if (frontMatter) {
        // Parse the frontMatter and find the title
        const [originalTitle, uselessKey, title] = frontMatter[1].match(
          /(title:\s*)(.+)/im
        );
        // These words should not be capitalised
        const smallWords = /^(a|an|and|as|at|but|by|en|for|if|in|nor|of|on|or|per|the|to|v.?|vs.?|via)$/i;
        // Split the title by spaces
        let newTitle = title
          .split(' ')
          // Loop through all the items
          .map((item, index, array) => {
            if (
              // Does it belong to the smallwords
              item.search(smallWords) > -1 &&
              // and it's not first or last word
              index !== 0 &&
              index !== array.length - 1
            ) {
              // This needs to be lowercase
              return item.toLowerCase();
            } else {
              // Everything else should be capitalised
              return item.replace(/^['A-Za-z']/, (item) => item.toUpperCase());
            }
          })
          .join(' ');

        // ======== NEW CODE FROM HERE =========

        // Replace the old title with the new one in the original content
        data = data.replace(originalTitle, `title: ${newTitle}`);
        fs.writeFile(file, data, (err, result) => {
          if (err) console.log('something went wrong with ' + file);
          console.log('Yay!');
        });
      }
    });
  });
});

There are better ways to do all this and more beautiful approaches, but it wasn't about that. I was probably bored a bit, so I did some quick hacky code and have my titles corrected. This could also be used to change headings in the document.

Oh, by the way, I didn't add any kind of report or validation since I'm using git for my blog and I can do a quick manual QA on commit.

The gist in Github.

Two repos I visited to get some inspiration from:

Talent Is Not Enough

2020-06-06T00:00:00+00:00

June 2019. Radiohead release MiniDiscs [Hacked], a compilation of demos and rehearsals from the creation of the OK Computer era, one of the greatest albums of the 90s.

If for some reason you haven't listened to this album or don't know Radiohead please do. Although I'm not sure if there is still a person - apart from Sheldon Cooper - that doesn't know who Radiohead is. Two pop culture references in two sentences, not bad for a start!

In these minidiscs, there was a lot of content, which wasn't really divided into songs or something, but eighteen parts with a total time of sixteen hours. I've listened to some of it and then I forgot about since then, but I revisited it in the last month since a youtube account is uploading these minidiscs based on songs which is, you know, a bit easier to listen to.

Both times, I got the same feeling. If you listen to these recordings, you are going to understand two things:

How talented these guys are.
How much work they put on these songs to get them to the point we all know from the album.

It was mind-blowing. I always thought that Thom Yorke and the rest of the gang just had some ideas, and effortless made a record. If you listen to these raw recordings, the experimentations and progress of their work is evident.

Success and excellence don't come easy. You have to work for it.

Boring Software Is Good

2020-05-30T00:00:00+00:00

Last night I was wandering around the internet reading a bunch of articles, and I ended up reading Basecamp’s blog. For some reason, this part of this random post really struck a chord.

We pride ourselves at Basecamp on being “boring software” because it just works and it’s always available.

This quote made me think. Each service/software has one or more pieces considered the core of this service. The main value of the product.

Now here come the questions:

Do you know which parts of the product are your core value?
If you could give a version number to each one of these parts, what would it be? And remember, it doesn’t matter how many iterations you’ve done. What matters is if you consider it to be stable, “boring”. If it just works.

Like you do, your customers have ROI (Return of Investment) in their vocabulary. They may join and pay for your product if you have some shiny things or extra features, but they will not stay if your core service - your main value proposition - is faulty.

Are you sure you are moving in the right direction?

Writing Beyond the Academy by Larry McEnerney

2020-01-13T00:00:00+00:00

Since I've started writing again - yes, do I write, I kid you not - I try to find ways to become better at it. During my search for resources, I stumbled upon this workshop by Larry McEnerney for the University of Chicago Writing Program.

McEnerney shares some thoughts on writing style, how it is related to your readers, how important is the value of your writings outside of academia and why. Great stuff there. I don't want to say too much and spoil it for you.

After the Intermission

2019-12-29T00:00:00+00:00

I surely have not written something in a long while. I've concluded that I have the urge to share, when I need an alternative way of expression.

A lot has changed since I started this blog. Back in 2016, I moved to another company and I had too much on my plate. I moved from a full-time Engineer to Scrum Master and now Engineering Manager. I've also learned a lot about how products are built. It wasn't easy, but I feel I have found my true calling and something that keeps me on my toes.

I have different experiences now and I want to share some of my thoughts on people management and leadership. This doesn't mean I will stop writing about code or anything else. I am just shifting my main focus to other stuff. Of course, I hope this might be helpful to other people too.

If you have visited before, here are some more changes you will notice:

New domain. No Github in it. Rants is something that can describe some of my posts, and I also find it funny!
A new layout, hopefully, more readable. I'm sure I'll have some debugging and code clean up to do.
An About section, in which I share more stuff about me and this blog. It's time to be a bit more out there.
Categories, in which you can find something you like, easier. Needs improvement I know.

That's all for now... Let's see how this will turn up!

Checking Your Open Ports With lsof

2019-05-02T00:00:00+00:00

Ok, some terminal stuff today. 💻

Have you ever thought about all these servers, databases, and other services we run in our machines and how vulnerable we become to malicious attacks?

Let me give you a simple example, I use the vue-cli to create and manage vue applications. Once you create an application, by default vue-cli exposes the port 8081 to everyone inside your network.

This means that everyone can visit http://myinternalip:8081 and see my application and do whatever he or she wants. I'm not saying that this is the cli's fault. I should be able to configure my application to listen only to my machine's request.

We are not going to cover here how to prevent this kind of situation but how we can see which of our processes are listening to every request.

How to check our open ports

Well, lsof FTW, which is a command that lists open files. In Unix systems this means "everything".

A colleague of mine sent me this which gives a list of ports that listen to requests:

lsof -i -P -n | grep LISTEN

Which translates to:

lsof -i // List all the connections
-P // show the port numbers (not names)
-n // Don't give me hostnames (IPs only)
| grep LISTEN // Find ports that are awaiting connections.

In our vue cli example you would see something like that:

node 69218 thanos 24u IPv4 0x89e5844963379b35 0t0 TCP \*:8081

When you see *:port means open to everyone. Everything else that has 127.0.0.1 or [::1] before the port will be listening only to local requests.

Here is another example with two Python simple servers. Based on our previous examples, one is open to everyone and one only in the local machine.

So, try to remember to bind your services to 127.0.0.1! :)

Bonus: Check this well written and quick article about lsof.

Andrew Shafer @ Cloud Foundry Summit 2014

2019-05-01T00:00:00+00:00

IE's InnerHTML Quirks

2017-04-08T00:00:00+00:00

The background

There are a lot of articles out there and StackOverflow threads about this, most of which come to the conclusion that we shouldn't do it. But let's face it, sometimes you have to parse the DOM or parts of the DOM with regular expressions, because it's faster.

It's a dirty job but someones gotta do it *

I'm not going to get into details, because it would be boring, but I had to parse an element with regular expression that would exclude some specific HTML tags from highlighting and process the rest.

Here is an example of the regex:

new RegExp('<span class=\"no-highlight.*?<\/span>|' + word, 'gi');

Everything worked find until the IE incident. For some reason the regex didn't worked as it should.

The debugging period

I run the function in the IE console with some "dummy" string which worked fine. Tried a lot of things without any solid result. I knew it was something simple, but I couldn't get my head around it. The local browserstack testing speed in IE didn't help either (loving the tool but sometimes local testing is a bitch).

The definition of insanity is doing something over and over again and expecting a different result. *

The epiphany

Then... what was my input? As I said before, my input was a DOM element, which means I would take the source with innerHTML or jQuery's .html() function. I did a console log of the input and I noticed something strange. The HTML source wasn't the same, IE had its own way of dealing with the order of the HTML attributes.

I've lost three hours of my life because of this stupid mistake.

Here is a simple example you can check the difference in any other browser than IE and IE itself (in a Windows machine of course).

When you get the innerHTML of an element in IE, its attributes are sorted by name, native attributes first. But if you add an attribute at runtime IE adds it at the end.

My regex would fail because of this. I did find I quick solution for this:

new RegExp('<span.[^>]*?class=\"no-highlight.*?<\/span>|' + word, 'gi');

I know the problems of this solution, but in my case there won't be any nesting in these tags because everything else is escaped.

TL;DR Don't use regular expressions to parse the DOM, but if you do, beware of the IE's attributes order.

Cheers!

Got Rid of Google Fonts and I Feel Fine

2017-03-24T00:00:00+00:00

I started writing in this blog in 2015, and I made a decision to use the Roboto font as my weapon of choice. Why? Actually, I'm not sure. But I did.

This means I have to add a script to my page to use the Google Font which adds ~36kb of data to this page. You can say it's not a significant amount for a page which usually has only text, but these are additional resources.

I do care about performance and UX. So, I use lazy loading with a fallback and a service worker which gets assets from cache after the client downloads the resource.

After some discussion with colleagues we ended up having some questions:

Does this make a difference to this blog?
Does this add any value to the user?

No - Nope - Nada. But let me explain what I mean.

Does it make a difference to this blog?

I'm not a brand or a product that is going to add some value to it. And if you think about it, the web is full of the Roboto font. My writings won't stand out because of the font I'm using. Getting better at this will (I really do try!).

Does it add any value to the user?

Well, no. If I use Helvetica (or Arial for windows and Linux machines) will have almost the same result. I'm not saying it's the same, but I wont make any big difference to the untrained eye. As I said before, the content will, and readability.

Here is a Roboto/Helvetica and here a Helvetica/Arial comparison.

Not a long time ago Github changed its stack to -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol". So, who am I to judge?

Having said that, at least for now I decided to remove the Roboto font and use the 'Helvetica, Arial, sans-serif' stack. I'm working on an Apple machine, so I'm going to do some experiments to get a great result to other systems too.

Also, now that I'm removing this dependency, I can also get some kb of the small JS that used to check when the web font available for use. These two changes I did reduced the home page resources from ~80kb to ~35kb. I say home page because in the article pages I have the Disqus dependency (at least for now).

TL;DR I got rid of the Google Fonts and I feel fine!

P.S. I'm not a typography expert (shocker!).

Cheers!

A Service Worker First Release

2016-07-25T00:00:00+00:00

I 've been experimenting for some time with progressive web apps and service workers. I know I am not the first one not even have the best implementation (google has already built a collection of tools for service workers), but this works and I am happy about it.

I just wanted to say that you can read the posts you have visited while you have internet connection available, when you are offline.

But what's next?

✔ Observe update issues with current service worker setup.
Implement better caching strategy for pages.
Fix a bug on mobile devices that offline fallback page doesn't get retrieved.
Maybe write a post about this experience and issues I've dealt with.
Implement offline google analytics.
✔ Maybe create a manifest file.
✔ Check score with google's Lighthouse (100 / 100).

Cheers!

First Steps With Facebook's Instant Articles

2016-04-25T00:00:00+00:00

Introduction

I think Instant Articles is the Facebook's way of saying "You had one job" to all developers out there. For me (a developer) is nothing more than a way to give your content to users fast without all the problems that our CMS's and code add to the user experience.

But I have one question:

If you are willing to do some work to give your content stripped down to a third party service, why can't you make the same things to you website to make it better?

Anyway I 'll give a mini start guide for the RSS feed thing for everyone who is interested, with some issues I dealt with.

What happened

Started working with Facebook's Instant Articles a few days ago. After two days of frustration I got my first articles consumed by this new Facebook feature. This might be due to my lack of patience with facebook's documentation or their lack of good documentation. I just tried the RSS way to add content to the Articles (Who the f*ck is going to add manually content to this thing FFS?!)

I'm not going to guide you through the steps of enabling the Instant Articles because there are ton of articles out there, but I am going to guide you through the painful work of creating a compatible RSS feed by yourself and not by using some plugin.

Let's start

First thing you need to do is go to your page and click Settings at the upper right corner and then Instant Articles at the left menu. If you can't find it, this means you haven't enabled Instant Articles for you page. Go back, do it and come back to this section.

For your first trial and error stuff we are going to need two thing from the tools section, the Claim your url and the Development RSS Feed.

For the Claim your Url tool first you need to add the og tag to your website tags inside <head></head> and then add you domain you are going to use to authorize your website to give RSS for this feature.

Now, the best part. You need to provide a url with your RSS file that you can do tests. Just write your url and don't be scared. This is a development feature. You can do anything you want and nothing goes public.

Forgot to say that you need to "Get the Pages Manager App" to preview your articles and styles on iOS or Android. Yeap, there is no other way to preview/debug your instant articles, only your mobile device!

I followed the instructions of facebook for a compatible RSS and built something like this:

<rss version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
<title>News Publisher</title>
<link>http://www.example.com/</link>
<description>
Read our awesome news, every day.
</description>
<language>en-us</language>
<lastBuildDate>2014-12-11T04:44:16Z</lastBuildDate>
<item>
<title>This is an Instant Article</title>
<link>http://example.com/article.html</link>
<content:encoded>
<![CDATA[
<!doctype html>
<html lang="en" prefix="op: http://media.facebook.com/op#">
<head>
<meta charset="utf-8">
<link rel="canonical" href="http://example.com/article.html">
<meta property="op:markup_version" content="v1.0">
</head>
<body>
<article>
<header>
<!— Article header goes here -->
</header>

              <!— Article body goes here -->

              <footer>
                <!— Article footer goes here -->
              </footer>
            </article>
          </body>
        </html>
        ]]>
      </content:encoded>
    </item>
    ....

</channel>
</rss>

As you see there is nothing special. Of course this had my content but these were my tags I wanted to use as I read in the documentation, right? Nope!

For some time I was changing things and trying the results but nothing happened, not even one error. I even tried using a 404 page to see if I was going to get any message from Facebook... Nope!(again)

After some time I was ready to give up and my last hope was installing Wordpress and the plugin for Instant Messages to see the differences and come up with a solution. After a while I found out that the only different thing was the pubDate.

What did you say? Facebook says it is not required? Yes it does:

After two days and one minute before going to a colleague or a stranger for help I saw my Development Instant Articles consuming my RSS feed. Just go to Publishing Tools from your top menu and then to your left side menu to your Instant Articles -> Development.

And just like that, I felt better!

But not for long. Added some more stuff like images, article text etc, but when I tried to see the articles in my mobile device I couldn't see the images and got some other errors from facebook. What I noticed was that my figure images where inside a paragraph tag because... editors!

The reason: Your wysiwyg editor sucks!

Facebook Instant Articles need clean HTML code. If your image is wrapped in a paragraph you have a problem. If your text isn't inside a paragraph you have a problem and other stuff that I haven't gotten into.

This means you may have to do some code-post-clean-up work.

2016-09-25 Update: Chris Coyer wrote a interesting article about making content available to Instant Articles, Apple News and AMP. Not everyone uses Wordpress (only the 25% of the internet websites do :P), but it'a a great case study.

That's all for now. Test and debug your articles and stay tuned to see if I manage to deliver the project and how! :P

Don't trust Facebook's documentation and build beautiful lightweight websites so we won't use third party services.

Cheers!

Upgrading Jekyll 2.x to 3.x

2016-02-04T00:00:00+00:00

At February 1st Github announced the upgrade of Jekyll from 2.4 to 3.0 for Guthub Pages. I thought this was the time to upgrade my local setup to the new version. I 've tried it some time ago but got some error and was too tired to debug anything, but now I had no choice.

Jekyll has a guide for upgrading but it wasn't enough for me. I ran gem update jekyll and tried to start my site with jekyll serve as always but I got the following errors.

Error Message #1

Deprecation: You appear to have pagination turned on, but you haven't included the jekyll-paginate gem. Ensure you have gems: [jekyll-paginate] in your configuration file.

That was easy, I just removed the paginate: setting from my _config.yml. I got no pagination so this was easier for me. If you have pagination in your site then you need to install the jekyll-paginate gem.

Error Message #2

Dependency Error: Yikes! It looks like you don't have kramdown or one of its dependencies installed. In order to use Jekyll as currently configured, you'll need to install this gem. The full error message from Ruby is: 'cannot load such file -- kramdown' If you run into trouble, you can find helpful resources at http://jekyllrb.com/help/!jekyll 3.1.1 Error: kramdown

This was a litle bit more complicated than I thought it would be.

At first I installed the kramdown gem but it kept returning me the same error message. The solution was to uninstall the old Jekyll verions with gem uninstall Jekyll.

After doing this I got one more error:

Error Message #3

Bundler could not find compatible versions for gem "jekyll": (Bundler::VersionConflict) In Gemfile: github-pages x64-mingw32 was resolved to 34, which depends on jekyll (= 2.4.0) x64-mingw32

I removed a Gemfile file I had in my folder and that worked for me.

If you have any more errors with your upgrade feel free to contact me to add them here!

A Simple BEM Advice

2016-01-11T00:00:00+00:00

For some time now I have been using the BEM methodology for production and I came to a conclusion.

"Don't get carried away!"

What I mean is, when I started using BEM I thought SASS will be my savior, I will use the sh*t out of '&' and don't ever repeat one single word...

This was a mistake. If you have a small project that won't scale it's okay, but if you have a big project that will grow, you and your colleagues are going to have a big problem. Code will get more and more complicated, even a simple navigation menu with some modifiers will be difficult to find the right line to change or add something.

Let me be more clear with an example.

.nav {

  &__item {
    display: inline;

    &--primary {
      background: blue;
    }
    &--dashed {
      border: 1px dashed #000;
    }

    &-link {
      color: #000;
      width: 100%;

      &--gray {
        background: gray;
        color: #fff;
      }
    }
    &-sub {
      &-link {
        .....
      }
    }
  }

}

This code after a while (or even now) will be incomprehensible. The solution is simple. Write some clean starting points. This code will sure be more readable if we change it to something like this

.nav__item {

  display: inline;

  &--primary {
    background: blue;
    display: block;
  }

  &--dashed {
    border: 1px dashed #000;
  }

}

.nav__item-sub {
  .....
}

.nav__item-link {

  color: #000;
  width: 100%;

  &--gray {
    background: gray;
    color: #fff;
  }
}

.nav__item-sub-link {
  .......
}

Now you will know what you are doing the next time you or someone else opens your SASS files.

Cheers!

Jekyll Workflow With Gulp

2016-01-09T00:00:00+00:00

Introduction

This weekend I decided to take this blog's design and create a theme. Of course it's not ready yet, because in the process of refactoring the SASS code I came across a problem. I 'm using flexbox but I didn't have prefixes! It's not the end of the world but this led to the fact that because of the github pages limitations I 'm limiting my workflow too. This is a problem.

Gulp to the rescue

So, we are going to include Gulp and some plugins to make our lives easier.

This process has two parts. The first one is the Jekyll's _config.yml configuration and the creation of a new folder we are going to have our development files, and our gulpfile.js configuration/setup.

Part I: Jekyll

Let's add some configuration to _config.yml.

exclude: ["_dev",
            "gulpfile.js",
            "node_modules",
            "package.json"]

exclude is a configuration setting variable in Jekyll's core to exlude paths or files from the site's conversion. (aka _site folder).

Exclude directories and/or files from the conversion. These exclusions are relative to the site's source directory and cannot be outside the source directory.

So, we don't want these files in our production site. I think it's pretty straightforward what we did here, but what you are goin to say is 'What the f*uck is the _dev folder?' and you 'll be right. The _dev folder is going to be the folder to keep our sass,js...(and whatever you want) source files which we don't want to be visible to the website.

Our project folder should be like this. The partials folder isn't mandatory, it's the way I structure my sass code. (if you feel comfortable tweaking the gulpfile.js you can work with any structure you want :) ):

|-- project
    |-- gulpfile.js
    |-- index.html
    |-- package.json
    |-- _config.yml
    |-- assets
    |   |-- css
    |   |   |-- style.css
    |   |-- img
    |   |-- js
    |-- _dev
    |   |-- src
    |       |-- sass
    |           |-- style.scss
    |           |-- partials
    |               |-- _base.scss
    |               |-- _functions.scss
    |               |-- _grid.scss
    |               |-- _layout.scss
    |               |-- _reset.scss
    |               |-- _syntax.scss
    |               |-- _variables.scss
    |-- _includes
    |-- _layouts
    |-- _posts
    |-- _site

And that's all we need to do for the Jekyll part.

Part II: Gulp

Now, let's install all the things!

You can copy paste this to a package.json file

{
  "devDependencies": {
    "gulp": "^3.9.0",
    "gulp-autoprefixer": "^3.1.0",
    "gulp-connect": "^2.3.1",
    "gulp-clean-css": "^2.0.13",
    "gulp-plumber": "^1.0.1",
    "gulp-rename": "^1.2.2",
    "gulp-sass": "^2.1.1",
    "gulp-util": "^3.0.7"
  }
}

and install by typing in your terminal

npm install

or create an empty package.json by typing

npm init

and follow the instructions to create a package.json file.

And then install by

npm install --save-dev gulp gulp-sass gulp-util gulp-plumber gulp-rename gulp-clean-css gulp-autoprefixer gulp-connect

Now we have our dependences let's build our gulpfile.js.

// Require all the things
const gulp = require('gulp'),
      sass = require('gulp-sass'),
      gutil = require('gulp-util'),
      plumber = require('gulp-plumber'),
      rename = require('gulp-rename'),
      minifyCSS = require('gulp-clean-css'),
      prefixer = require('gulp-autoprefixer'),
      connect = require('gulp-connect');
      cp = require('child_process');

// Set the path variables
const base_path = './',
      src = base_path + '_dev/src',
      dist = base_path + 'assets',
      paths = {
          js: src + '/js/*.js',
          scss: [ src +'/sass/*.scss',
                  src +'/sass/**/* .scss',
                  src +'/sass/**/**/*.scss'],
          jekyll: ['index.html', '_posts/*', '_layouts/*', '_includes/*' , 'assets/*', 'assets/**/*']
      };


// Compile sass to css
gulp.task('compile-sass', () => {
  return gulp.src(paths.scss)
    .pipe(plumber((error) => {
        gutil.log(gutil.colors.red(error.message));
        gulp.task('compile-sass').emit('end');
    }))
    .pipe(sass())
    .pipe(prefixer('last 3 versions', 'ie 9'))
    .pipe(minifyCSS())
    .pipe(rename({dirname: dist + '/css'}))
    .pipe(gulp.dest('./'));
});

// Rebuild Jekyll
gulp.task('build-jekyll', (code) => {
  return cp.spawn('jekyll', ['build', '--incremental'], { stdio: 'inherit' }) // Adding incremental reduces build time.
    .on('error', (error) => gutil.log(gutil.colors.red(error.message)))
    .on('close', code);
})

// Setup Server
gulp.task('server', () => {
  connect.server({
    root: ['_site'],
    port: 4000
  });
})

// Watch files
gulp.task('watch', () => {
  gulp.watch(paths.scss, ['compile-sass']);
  gulp.watch(paths.jekyll, ['build-jekyll']);
});

// Start Everything with the default task
gulp.task('default', [ 'compile-sass', 'build-jekyll', 'server', 'watch' ]);

Important For Windows users: You need to replace in the build-jekyll task the 'jekyll' string with the path of your jekyll.bat. In my case it was in the C:\Ruby22-x64\bin so I changed this code to:

2016/11/20 Update: As Ron Dyar commented, in some Windows OS cases a jekyll.bat is enough, without the path. You can try both and see which one works for you.

// Rebuild Jekyll
gulp.task('build-jekyll', (code) => {
  return cp.spawn('C:\\your_ruby_path\\bin\\jekyll.bat', ['build'], {stdio: 'inherit'})
    .on('error', (error) => gutil.log(gutil.colors.red(error.message)))
    .on('close', code)
})

2016/01/10 Update: Alex Lockwood was kind enough to create a gist for older npm versions on which ES6 features cause errors.

2017/02/11 Update: A user's comment I cannot find requested to update the ruby path with a newer version. So, in the your_ruby_path you need to set your ruby path. For example, mine was Ruby22-x64 at the time.

Now, if you don't care to know how this works or why, just copy/paste all these we talked about, and when you are ready just execute in your terminal gulp and you can go to http://localhost:4000 and see your site. All changes will be watched and compiled.

What our gulpfile does:

Builds Jekyll
Minifies/compiles/autoprefixes SASS
Sets up a local server
Watches our source files(Jekyll's and static assets) and recompile when changes on update.

Let's see what each plugin does for our case:

gulp: You know what this does!

gulp-sass: Takes our sass files and compiles them to css.

gulp-util/gulp-plumber: Some gulp utilities to catch and report errors. For some reason the gulp-sass plugin stops gulp on error and we have to start it again, so with these two we can prevent that.

gulp-rename: Renames our CSS files because if we didn't we would get a file like this /assets/css/src/css/style.css.

gulp-~~minify~~clean-css: Simple!

gulp-autoprefixer: What started all this! This prefixes our css. There are some great options for this plugin, be sure to check them out! Github

gulp-connect: Setups a local web server to preview our site. It's inevitable because we can't use jekyll serve like we did before.

child_process: This is not a plugin. This is a Node.js core module. We are using this because (very roughly) Gulp is running in one process and we need to run the jekyll build process at the same time, we cannot stop Gulp. So we are 'attaching' the jekyll command to a child process that returns that everything went fine when it finishes. I want to see this in depth but I got carried away with the Windows problem I warned you before.

That's it! As I said before just run gulp and work with your masterpiece!

Conclusion

Having this workflow might be strange at the beginning but it will help you, I promise. I didn't include the js files manipulation on purpose so that you can do some tests. But it will be available to the theme workflow I am working right now. Stay tuned!

If you have and questions or comments don't hesitate to contact me here or at my twitter account.

Cheers!

Working With ES6 in the Browser

2016-01-05T00:00:00+00:00

These are some ways to work with ES6 in the browser. We are going to use Babel 6 as our transpiler and Gulp as our task runner.

The playground

If you just want to test some of the new features first we must install the following by:

Creating a package.json and add the gulp, gulp-babel, gulp-concat, gulp-sourcemaps, babel-preset-es2015 dependences in it and execute npm install

{
  "devDependencies": {
    "babel-preset-es2015": "^6.3.13",
    "gulp": "^3.9.0",
    "gulp-babel": "^6.1.1",
    "gulp-concat": "^2.6.0",
    "gulp-sourcemaps": "^1.6.0"
  }
}

or just in our command line

npm install --save-dev gulp gulp-babel gulp-sourcemaps gulp-concat babel-preset-es2015

Some explanation of the plugins:

| ------------------- |:-----------------------------------------:| | gulp | The task/build runner to glue everything | | babel | Transforms our ES6 to ES5* | | gulp-sourcemaps | For better Debugging | | gulp-concat | Concatenates files (js for us) | | babel-preset-es2015 | Transforms our ES6 to ES5* |

*As of version 6 Babel doesn't transpile ES2015 by default.

Since Babel is focusing on being a platform for JavaScript tooling and not an ES2015 transpiler, we’ve decided to make all of the plugins opt-in. This means when you install Babel it will no longer transpile your ES2015 code by default.

After we install all our plugins we need to create a gulpfile.js with the following content:

const gulp = require('gulp'),
      babel = require('gulp-babel'),
      concat = require('gulp-concat'),
      sourcemaps = require('gulp-sourcemaps');

gulp.task('babel-js', () => {
  return gulp.src('src/*.js')
    .pipe(sourcemaps.init())
    .pipe(babel({
        presets: ['es2015']
    }))
    .pipe(concat('app.js'))
    .pipe(sourcemaps.write('.'))
    .pipe(gulp.dest('dist'));
});

gulp.task('watch', () => {
  gulp.watch('src/app.js', ['babel-js']);
});

gulp.task('default', ['babel-js', 'watch' ]);

For our html file we just need to add our app.js file to our simple html structure:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>ES6 Browser Starter</title>
</head>
<body>

<script src="./dist/app.js"></script>
</body>
</html>

Now that all our scripts and files are ready, our directory structure should look like this:

    |-- gulpfile.js
    |-- index.html
    |-- package.json
    |-- dist
    |-- src
        |-- app.js

We execute gulp in our terminal and any change in our javascript files will be watched and compiled.

Let's get serious

That was fun, but if we want to use modules requires a different setup. This time we are going to use Browserify to bundle our module. You can check how to do this with Webpack in a previous post.

Like before, we need to install our dependences by creating this package.json:

{
  "devDependencies": {
    "babel-preset-es2015": "^6.3.13",
    "babelify": "^7.2.0",
    "browserify": "^12.0.1",
    "gulp": "^3.9.0",
    "gulp-rename": "^1.2.2",
    "gulp-util": "^3.0.7",
    "vinyl-buffer": "^1.0.0",
    "vinyl-source-stream": "^1.1.0",
    "watchify": "^3.6.1"
  }
}

or by command line:

npm install --save-dev babel-preset-es2015 babelify browserify gulp gulp-rename gulp-util vinyl-buffer vinyl-source-stream watchify

What our new gulp plugins do:

| ------------------- |:-----------------------------------------:| | babelify | Browserify transform for Babel. This will transpile our ES6 code to ES5 | | Browserify | Browserify lets you require('modules') in the browser by bundling up all of your dependencies. This will make our modules work in the browser when we 'll transpile our ES6 code to ES5 | | gulp-rename | Rename files | | gulp-util | Utilities for gulp plugins. We are using it here to get a colorful message of successful bundle | | vinyl-buffer | Transforms our bundle to Gulp stream | | vinyl-source-stream | Transforms our bundle to Gulp stream | | watchify | Watches for updates in our browserify files and recompiles them. |

Our gulpfile.js

"use strict"

const gulp = require('gulp'),
      babelify = require('babelify'),
      browserify = require('browserify'),
      source = require('vinyl-source-stream'),
      buffer = require('vinyl-buffer'),
      watchify = require('watchify'),
      rename = require('gulp-rename'),
      gutil = require('gulp-util');


const config = {
        src: './src/app.js',
        dest: './dist/'
      };

let bundle = (bundler) => {
  bundler
    .bundle()
    .pipe(source('bundled-app.js'))
    .pipe(buffer())
    .pipe(rename('bundle.js'))
    .pipe(gulp.dest(config.dest))
    .on('end', () => gutil.log(gutil.colors.green('==> Successful Bundle!')));
}

gulp.task('default', () => {

  let bundler = browserify(config.src, {debug: true})
                  .plugin(watchify)
                  .transform(babelify, {presets: ['es2015']});

  bundle(bundler);

  bundler.on('update', () => bundle(bundler));
});

Let's start from the bottom.

let bundler = browserify(config.src, {debug: true})
                  .plugin(watchify)
                  .transform(babelify, {presets: ['es2015']});

Our default task is creating a bundler variable with a browserify object. Takes two parameters, one is our source file and the second one is to return inline sourcemaps in our bundle.js file. Then adds the watchify plugin and transforms it with babelify to ES5 code.

bundle(bundler);

  bundler.on('update', () => bundle(bundler));

This part of code calls the bundle function for the first time and adds the on update event to recall it when our source code changes.

let bundle = (bundler) => {
  bundler
    .bundle()
    .pipe(source('bundled-app.js'))
    .pipe(buffer())
    .pipe(rename('bundle.js'))
    .pipe(gulp.dest(config.dest))
    .on('end', () => gutil.log(gutil.colors.green('==> Successful Bundle!')));
}

The bundle function bundles our code and puts the result in our destination folder.

For this example we are going to create one more js file to test our module works.

Important: Remember to put './' in front of the import folder. I lost a lot of time because I forgot to.

//---- ./app.js

  import {y} from './libs/simpleModule';
  y();

  //---- ./libs/simpleModule.js
  export function y() {
    console.log('This is a Module!');
  }

For this html file we are going to change our app.js from our previous example with the bundle.js.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>ES6 Browser Modules</title>
</head>
<body>

<script src="./dist/bundle.js"></script>
</body>
</html>

And our folder structure must be something like this right now.

    |-- gulpfile.js
    |-- index.html
    |-- package.json
    |-- dist
    |-- src
        |-- app.js
        |-- libs
            |-- simpleModule.js

Just execute gulp in your terminal and any change in your javascript files will be watched and compiled. If everything went well you should be able to see the '==> Successful Bundle!' message.

Create an ES6 Module

2015-12-27T00:00:00+00:00

Introduction

ES6 Time! I decided to migrate the share buttons script to ECMASCRIPT 6.

First some things I want to say:

This is a prototype that may contain errors in code or concept. I am open to suggestions :)
I just started, and if you are interested in ES6 you should too, reading the "Exploring ES6 - Upgrade to the next version of JavaScript" by Axel Rauschmayer.
I started this code by reading this chapter from this book and using this repository.
The code of this article is available in my github account in this repository to check it out.

What's this post about

This post is about creating a small ES6 module we created in a previous post about Share Buttons Performance and a script to avoid all these problems. It's a simple script that scans the dom for a specific class and adds a click event.

ES6 fast catchup

To fully understand this post you 'll need to understand some basic ES6 features. This is a rough explaination of these features, you should take a look at Axel Rauschmayer's book for more in depth stuff.

VAR vs LET

In ES6 we can use let to create block variables. Here is an example from MDN:

function varTest() {
  var x = 31;
  if (true) {
    var x = 71;  // same variable!
    console.log(x);  // 71
  }
  console.log(x);  // 71
}

function letTest() {
  let x = 31;
  if (true) {
    let x = 71;  // different variable
    console.log(x);  // 71
  }
  console.log(x);  // 31
}

I noticed that if you set with let the same variable in the same block you 'll get an error.

let x = 2;
    let x = 4;
    // Uncaught TypeError: unknown: Line 2: Duplicate declaration "x"

Arrow functions

In my opinion the main difference of using arrow functions is that the word this doesn't refer to the current arrow function's scope but to some parent function that has a this definition (We will see this in our code later). This means no more that = this etc but this can be tricky, especially inside modules.

But here are some examples:

// No parameters (parenthesis is required)
    let logMe = () => console.log('ME!');

    logMe();

    // One parameter (can ommit parenthesis)
    let logMe = name => console.log(name);

    logMe('Jim');

    // More than one parameter (parenthesis is required)
    let logMe = (what, name) => console.log(what + ' ' + name);

    logMe('Hello', 'Jim');

    // More than one parameter and multiple line expression
    let logMe = (what, name) => {
        let text = what + ' ' + name;
        console.log(text);
    };

    logMe('Hello', 'Jim');


    /*
        The `this` scope. this will refer to the logMe() and not the setTimeout function.
        There is no `this` inside that arrow function.
    */

    function logMe() {
        setTimeout(() => {
            console.log("Who:", this.name);
        },500);
    };

    // or
    function logMe() {
        setTimeout(() => console.log("Who:", this.name),500);
    };

    logMe.call({name: 'Jim'})();

Template Strings

Yay! No more errors in your string templates! From MDN:

Template strings are enclosed by the back-tick (``) (grave accent) character instead of double or single quotes. Template strings can contain place holders. These are indicated by the Dollar sign and curly braces (${expression}). The expressions in the place holders and the text between them get passed to a function. The default function just concatenates the parts into a single string. If there is an expression preceding the template string (tag here), the template string is called "tagged template string". In that case, the tag expression (usually a function) gets called with the processed template string, which you can then manipulate before outputting.

There is so much to learn about this but we are just going to cover the very basics just like we did before. Here is how we are going to use our logMe() with the new shiny string templates.

// The old way
    let logMe = (what, name) => {
        let text = what + ' ' + name;
        console.log(text);
    }

    // The New way
    let logMe = (what, name) => {
        let text = `${what} ${name}`;
        console.log(text);
    };

    // or even in a crazy ugly multiline string
    let logMe = (what, name) => {
        let text = `I just wanted to
         say ${what} to my friend
                    ${name}`;
        console.log(text);
    };

Modules

Last but not least, the modules. At last in ES6 we can create and use our modules in separate files and import them without any third party libraries. And this is what this post is about, building a simple module. But let's cover the basics.

In ES6 we can use export and have one default export for a function or a class per module, or use named exports to export as many functions as we want per module. We are going to use two .js files, our module file called myLogModule.js and our main.js to import our module.

This is an example with a default export. This can be a function or a class.

// myLogModule.js
    export default function(text) {
        console.log(`This is from myLogModule and it says ${text}`)
    };

    // main.js
    import whateverNameYouWant from './myLogModule';
    whateverNameYouWant('hello');

If we were going to use named exports this is what we were going to do.

// myLogModule.js
    export function saySomething(text) {
        console.log(`This is from myLogModule and it says ${text}`);
    };
    export function saySomethingElse(text) {
        console.log(`This is something else ${text}`);
    };


    // main.js
    import * as myLogModule from './myLogModule';

    myLogModule.saySomething('hellooooo');
    myLogModule.saySomethingElse('hello again');

Or we can always import a specific function in our main.js

// main.js
    import {saySomething} from './myLogModule';
    saySomething('hellooooo');

Or more than one

// main.js
    import {saySomething, saySomethingElse} from './myLogModule';
    saySomething('hellooooo');
    saySomethingElse('hello again');

That's a very (really) rough explaination of these features, but I am sure these are enought to continue with our own module.

Our Module

As I said before we are going to create our own module to see a more 'complex' situation. The script we are going to use is this and all it does is search the dom for elements with a .js-share-button class and add a click event listener to each element that opens a window with a share url for facebook or twitter.

This is the script in 'traditional' javascript:

shareButtons = function(){

  // Select all our buttons with the js-share-button class
  var shareButtons = document.querySelectorAll('.js-share-button');

  var init = function(){
    add_listeners_to_buttons();
  };

  var window_open = function(url){
    window.open(url, '', 'menubar=no,toolbar=no,resizable=yes,scrollbars=yes,width=500,height=300');
  };

  var add_listeners_to_buttons = function(){

    for (var i = 0; i < shareButtons.length; i++) {

      // Add a click handler to each of our buttons
      shareButtons[i].addEventListener('click', function(e) {
        e.preventDefault();

        // Get the service from the data attribute
        var service = this.getAttribute('data-service'),

        // Gets the href from our link (Good for ajax)
            page_url = encodeURIComponent(this.href),
            url = '';

        // Check which service we want and attach the right url.
        // window.location give the current url.
        //
        // IMPORTANT! Always remember we need to encode our urls
        //            and variables we are sending.
        switch (service) {
          case 'facebook':
            url+= 'https://www.facebook.com/sharer/sharer.php?u='
               + page_url;
            break;
          case 'twitter':
            url+='https://twitter.com/intent/tweet/?text=' + encodeURIComponent(this.title);
            url+='&url=' + page_url;
            break;
          default:
            console.log('There is no such share service in your `switch`!');
            break;
        }

        window_open(url);
      });
    }
  };

  // Return to the user only the init function
  return{init:init}
}();

// Just call this function to initiate everything.
shareButtons.init();

What we need to create is a main.js file as we had in our examples before, and a ShareButtons.js file with our module and begin by writing the functions we are going to use in our module.

ShareButtons.js

We can use let instead of var for everything without getting and error. This was a trial and error to for me. Every traditional function code is replaced with arrow functions. This module still reveals only the init function to the user.

let shareButtons = function(){

        // Select all our buttons with the js-share-button class
        let shareButtons = document.querySelectorAll('.js-share-button');

        // There are no parameters, so a parenthesis is ok here.
        let init = () => {

        };

        //  No need for a parenthesis here we got one parameter
        let window_open = url => {

        };

        let add_listeners_to_buttons = () => {

        };

        // Return to the user only the init function
        return{init:init}
    }();

Nothing else is changed in our init or window_open function

let init = () => {
    add_listeners_to_buttons();
  };

  let window_open = url => {
    window.open(url, '', 'menubar=no,toolbar=no,resizable=yes,scrollbars=yes,width=500,height=300');
  }

The most interesting parts are in the add_listeners_to_buttons function.

First of all instead of using a for(var i=....) function we used the new ES6 for...of to iterate through our array of elements. Then we replaced our traditional string concatenation with the new ES6 string templates as we did in our examples before. That was easy and fun, I must say!

let add_listeners_to_buttons = () => {

    for (let button of shareButtons) {
      button.addEventListener('click', e => {
        e.preventDefault();

        let service = button.getAttribute('data-service'),
            title = encodeURIComponent(button.title),
            page_url = encodeURIComponent(button.href),
            url = '';

        switch (service) {
          case 'facebook':
            url = `https://www.facebook.com/sharer/sharer.php?u=${page_url}`;
            break;
          case 'twitter':
            url = `https://twitter.com/intent/tweet/?text=${title}&url=${page_url}`;
            break;
          default:
            console.log(`There is no ${service} share service in your 'switch'!`);
            break;
        }

        window_open(url);
      });
    }
  };

And now the evil event listener with arrow function and this!

First I tried using this.getAttribute() and never worked. Of course it never worked, it returned undefined, because this doesn't refer to the dom element but to some parent function.

button.addEventListener('click', e => {
        e.preventDefault();

        let service = button.getAttribute('data-service'),
            title = encodeURIComponent(button.title),
            page_url = encodeURIComponent(button.href),
            url = '';
        ...
    });

After some research(google it) and some experemental time I came to the conclusion that I could either use a traditional function(e) {} to get this to work or (the experemental time we talked about) use the button variable that keeps the dom element. I wasn't sure this would work but there was no error and the buttons worked whithout a problem. Up to this time I 'm sure there is a way to make arrow functions and this work inside an event listener but I don't know it.

Another conceptual 'problem' I faced was the "What I am going to export? The main function? The init? What I am talking about? I just want to give the init to the user will the function export expose the other functions too?" and other fun things like these. At the end, it was easy, I needed to export the ShareButtons function and expose only the init() like I did before. Nothing else will be visible to the user.

So to export our module we add to the end of our ShareButtons.js file export default shareButtons;. And that's all for our module. It's ready. I know this wasn't difficult but if you create it from scratch you are going to face some problems - or not. I did :).

Remember, we could make this a class or we could separate our window_open to another module and use it in our module to make things more interesting.

So, this is our complete module:

let shareButtons = function(){

  // Select all our buttons with the js-share-button class
  let shareButtons = document.querySelectorAll('.js-share-button');

  let init = () => {
    add_listeners_to_buttons();
  };

  //  No need for a parenthesis here we got one parameter
  let window_open = url => {
    window.open(url, '', 'menubar=no,toolbar=no,resizable=yes,scrollbars=yes,width=500,height=300');
  };

  let add_listeners_to_buttons = () => {

    for (let button of shareButtons) {
      /*
        We cannot use an arrow function because `this` will return `undefined`.
        So, we are using the button variable to have the preferred functionality.
      */
      button.addEventListener('click', e => {
        e.preventDefault();

        let service = button.getAttribute('data-service'),
            title = encodeURIComponent(button.title),
            page_url = encodeURIComponent(button.href),
            url = '';

        switch (service) {
          case 'facebook':
            url = `https://www.facebook.com/sharer/sharer.php?u=${page_url}`;
            break;
          case 'twitter':
            url = `https://twitter.com/intent/tweet/?text=${title}&url=${page_url}`;
            break;
          default:
            console.log(`There is no ${service} share service in your 'switch'!`);
            break;
        }

        window_open(url);
      });
    }
  };

  // Return to the user only the init function
  return{init:init}
}();

export default shareButtons;

main.js

For our main.js file things are much easier. We just import our module as we did before and call the init function.

import ShareButtons from './ShareButtons';

ShareButtons.init();

The code

You can try this code by downloading this repository from my github account.

Conclusion

Well, this was a big and fun post, at least for me.

As I said before, ES6 is new to me and I 'm sure there are some errors in my concept or the code and it would be great if someone has any comment on this to make it better. Cheers!

Create Custom Domains for Development in XAMPP

2015-12-12T00:00:00+00:00

If you are developing sites the you 've come to a place where you are furstrated with constantly having to change things when you move to production such as changing urls to get the thing work. We spent three hours of our lives with a friend of mine to reconfigure a Wordpress site from a XAMPP server to production server. Another example I can think of is the Laravel's public folder, I don't want to go to localhost/site/public each time, a mywebsite.com would be fine.

The best thing you could do is configure your local setup as your production server. To do this we need to edit our hosts file and our httpd-vhosts.conf file.

Hosts File

Just go to your C:\Windows\System32\drivers\etc, edit(as administrator) your hosts file and add your preffered domain. For this example I used yourdomain.io. Remember, my driver is 'C:', yours might be something else.

When you do this open your command and type ipconfig /flushdns to flush your local dns settings.

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
# 127.0.0.1       localhost
# ::1             localhost
127.0.0.1      yourdomain.io

By doing this you can access any site in your local development by using yourdomain.io/site but this isn't enough. We must configure something in our apache server to be more specific.

httpd-vhosts.conf File

Navigate to 'your XAMPP install folder\apache\conf\extra', for me is 'C:\xampp\apache\conf\extra' and edit your httpd-vhosts.conf file. Just copy/paste one of the example in this file and use the ones you want. Remember to uncomment each line by removing the '##' before the line and we are set to go!

# Virtual Hosts
#
# Required modules: mod_log_config

# If you want to maintain multiple domains/hostnames on your
# machine you can setup VirtualHost containers for them. Most configurations
# use only name-based virtual hosts so the server doesn't need to worry about
# IP addresses. This is indicated by the asterisks in the directives below.
#
# Please see the documentation at
# <URL:http://httpd.apache.org/docs/2.4/vhosts/>
# for further details before you try to setup virtual hosts.
#
# You may use the command line option '-S' to verify your virtual host
# configuration.

#
# Use name-based virtual hosting.
#
##NameVirtualHost *:80
#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for all requests that do not
# match a ##ServerName or ##ServerAlias in any <VirtualHost> block.
#
##<VirtualHost *:80>
    ##ServerAdmin webmaster@dummy-host.example.com
    ##DocumentRoot "C:/xampp/htdocs/dummy-host.example.com"
    ##ServerName dummy-host.example.com
    ##ServerAlias www.dummy-host.example.com
    ##ErrorLog "logs/dummy-host.example.com-error.log"
    ##CustomLog "logs/dummy-host.example.com-access.log" common
##</VirtualHost>

##<VirtualHost *:80>
    ##ServerAdmin webmaster@dummy-host2.example.com
    ##DocumentRoot "C:/xampp/htdocs/dummy-host2.example.com"
    ##ServerName dummy-host2.example.com
    ##ErrorLog "logs/dummy-host2.example.com-error.log"
    ##CustomLog "logs/dummy-host2.example.com-access.log" common
##</VirtualHost>

<VirtualHost *:80>
    ServerAdmin something@yourdomain.io
    DocumentRoot "C:/xampp/htdocs/yoursite"
    ServerName yourdomain.io
    ServerAlias www.yourdomain.io
</VirtualHost>

Just in case start and stop your apache service. Next thing you got to do is navigate to your url by typing www.yourdomain.io in your browser.

Share Buttons Performance Issues

2015-11-24T00:00:00+00:00

Last week we had a series of interviews with a number of candidates for a junior frontend developer position and at the end of each session we gave them a "code challenge" to complete in their spare time, only if they wanted to. Nothing special, just a simple responsive prototype so as to take a peak at the quality of their code.

One thing we had in this prototype was a Facebook share button to see how they could deal with it. There was no restriction to it, they could use any library, service or code snippet they could think of.

Almost a 40% of the candidates used a simple link which redirected you to a facebook share page, a 30% used a third party library and a 30% used Facebook's default share button.

The first thing that comes to my mind is: Don't use social network's share buttons, it's bad for the page's performance.

There is always a simple solution to this. With some lines of code you can share your content without loading all these resources that come with the official share buttons.

I know this subject has been covered by many people but here is an example for facebook and twitter share buttons without messing with external libraries.

Code

Here is the HTML code for the buttons. We are just creating simple links. We use the js-share-button class in our script to select all the share buttons. And the data-service attribute gives us the services we are going to use.

<a href="https://codegazerants.com/2015/11/24/share-buttons-performance/" class="share__button facebook js-share-button" data-service="facebook">Share on Facebook</a>
<a href="https://codegazerants.com/2015/11/24/share-buttons-performance/" class="share__button twitter js-share-button" data-service="twitter" title="Share Buttons Performance Issues and how to deal with them - @codegaze">Share on Twitter</a>

And the javascript code for it with some comments to explain what's going on.

<script>

  // Select all our buttons with the js-share-button class
  var shareButtons = document.querySelectorAll('.js-share-button');


  for (var i = 0; i < shareButtons.length; i++) {

    // Add a click handler to each of our buttons
    shareButtons[i].addEventListener('click', function(e) {
      e.preventDefault();

      // Get the service from the data attribute
      var service = this.getAttribute('data-service'),
          url = '';

      // Check which service we want and attach the right url.
      // window.location give the current url.
      //
      // IMPORTANT! Always remember we need to encode our urls
      //            and variables we are sending.
      switch (service) {
        case 'facebook':
          url+= 'https://www.facebook.com/sharer/sharer.php?u='
             + encodeURIComponent(window.location);
          break;
        case 'twitter':
          url+='https://twitter.com/intent/tweet/?text=' + encodeURIComponent(this.title);
          url+='&url=' + encodeURIComponent(window.location);
          break;
        default:
          console.log('There is no such share service in your `switch`!');
          break;
      }

      window.open(url, '', 'menubar=no,toolbar=no,resizable=yes,scrollbars=yes,width=500,height=300');

    });

  }
  </script>

Update 12/12/2015

I wanted to create a module for this script so I can use it to ajax elements too. This could be better, for example the window_open function could be in another module with global small utilities but this is good for now. The only difference for the user is that the URL comes from the link and not from the current page. This is great when you got an ajax list you want to share each item.

Just use shareButtons.init(); when you want to parse the DOM.

<script>

shareButtons = function(){

  // Select all our buttons with the js-share-button class
  var shareButtons = document.querySelectorAll('.js-share-button');

  var init = function(){
    add_listeners_to_buttons();
  };

  var window_open = function(url){
    window.open(url, '', 'menubar=no,toolbar=no,resizable=yes,scrollbars=yes,width=500,height=300');
  }

  var add_listeners_to_buttons = function(){

    for (var i = 0; i < shareButtons.length; i++) {

      // Add a click handler to each of our buttons
      shareButtons[i].addEventListener('click', function(e) {
        e.preventDefault();

        // Get the service from the data attribute
        var service = this.getAttribute('data-service'),

        // Gets the href from our link (Good for ajax)
            page_url = encodeURIComponent(this.href),
            url = '';

        // Check which service we want and attach the right url.
        // window.location give the current url.
        //
        // IMPORTANT! Always remember we need to encode our urls
        //            and variables we are sending.
        switch (service) {
          case 'facebook':
            url+= 'https://www.facebook.com/sharer/sharer.php?u='
               + page_url;
            break;
          case 'twitter':
            url+='https://twitter.com/intent/tweet/?text=' + encodeURIComponent(this.title);
            url+='&url=' + page_url;
            break;
          default:
            console.log('There is no such share service in your `switch`!');
            break;
        }

        window_open(url);
      });
    }
  };

  // Return to the user only the init function
  return{init:init}
}();

// Just call this function to initiate everything.
shareButtons.init();

</script>

You can check the demo of these buttons, will give you a share to the current page url.

Share on Facebook Share on Twitter

Modern Workflow + Tooling for Front-end Developers

2015-11-13T00:00:00+00:00

Wes Bos at Fronteers Conference 2015 gives a short presentation for each of the modern workflow tools front-end developers are using right now and a bonus talk with Bruce Lawson asking people's questions.

Wes Bos - Modern Workflow + Tooling for Front-end Developers from Fronteers on Vimeo.

Responsive Rounded Buttons

2015-10-30T00:00:00+00:00

Last week I wanted to create three rounded buttons for a client's site.

I didn't keep it in the design but here is some code and explaination of how this is done for responsive cases.

First of all our button needs to have a wrapper with a width. For our example we are going to use a list.

li {
  width: 15%;
  display: inline-block;
}

Now, each button needs to have 100% width and magic trick number 1: we give a zero height and a padding-bottom: 100% to resize the height fluidly. And overflow: hidden to hide the remaining color of the link.

.button {
  width: 100%;
  height: 0;
  padding-bottom: 100%;
  border-radius: 50%;
  overflow: hidden;
}

For the next part, our link needs to have padding-top: 50%; & padding-bottom: 50%; to be in the "middle" of the link and a margin-top half the size of the line-height to create an "absolute middle". It's the same logic with absolute centering things.

.button__link {
    border: 1px solid red;
    display: block;
    width: 100%;
    padding-top: 50%;
    padding-bottom: 50%;
    text-align: center;
    color: #fff;
    text-decoration: none;
    line-height: 2em;
    font-size: 2em;
    margin-top: -1em;
    background: #E9C46A;
  }

Here is a demo of what we created and the sass code for it.

li {
  width: 15%;
  display: inline-block;
}

.button {
  width: 100%;
  height: 0;
  padding-bottom: 100%;
  border-radius: 50%;
  overflow: hidden;

  &__link {
    border: 1px solid red;
    display: block;
    width: 100%;
    padding-top: 50%;
    padding-bottom: 50%;
    text-align: center;
    color: #fff;
    text-decoration: none;
    line-height: 2em;
    font-size: 2em;
    margin-top: -1em;
    background: #E9C46A;
  }
}

That's all you need to know to work with rounded buttons. Below there is a new "section" you can check out about status when I write each post.

Maybe it works for you too :).

A Modal Alternative Proposal

2015-10-19T00:00:00+00:00

When I saw modals some years ago, I thought it was one of the best things happened. Just use a plugin and show your important stuff to the user and you are ready to go. Things changed since then and plugins went bigger and better, but I think we are using tooooo many resources and third party libraries and we need to stop.

In my projects I usually use a modal either to show a new feature (announcement) to the user or in a photo gallery or something like this. I am ok with the latter - although there is always another solution - but when it comes to the first we can always choose a more lightweight and simplified way.

Here is what I am proposing (live demo):

Add your big announcement in your content. Use just a small script to close your "modal". No more big chunks of js and css.

With this solution the user has three options:

Ignore it.
Close it.
Click it.

Please, don't auto close your message. If the user ignores it and continues to read your content it will be annoying to remove it while he reads something.

And if someone clicks the close button, give that person a cookie for a while. He clicked it for a reason.

Here is the small script I talked about before:

function closeModulePromo() {

  var module_element = document.getElementById('module_promo');
  module_element.parentElement.removeChild(module_element);

}

var module_close_handler = document.getElementById('module_promo_close');

module_close_handler.onclick = function() {
  closeModulePromo();
}

Notes:
In my demo I don't use a cookie.
I used a https://www.initializr.com/ boilerplate for the demo.
Maybe I'll do another part about an image gallery version.

If you have any questions or reccomendations, feel free to comment.

Better UX for Users With Ad Blockers

2015-10-17T00:00:00+00:00

Let me start by saying that preventing people from using your content if they use an ad blocker is unethical. All this fuzz about ad blockers and no one says that ad blockers may block a site feature too.

The problem

Some time ago I built a site for a client which had an iframe with a third party service for booking tickets. We were getting complains from users that couldn't see the widget.

After some research we found out that these users had an ad blocker enabled, and we needed to find a way, not to bypass this but inform our users that they are missing a service.

I repeat: Please use this to provide to your user a better experience.

The solution

Usually ad blockers remove the content they think it's an add and put some inline styling to remove any unwanted white space. So what we need to do is check for any "suspicious" styling in our widget.

function checkAdBlocker(iframe_id, error_message_id) {

    var iframe_element = document.getElementById(iframe_id),
        error_meesage_element = document.getElementById(error_message_id);

    if (iframe_element.style.height === 0 || iframe_element.style.display == 'none') {
      error_meesage_element.classList.remove('hidden');
    }
  }

This script checks our widget height and display status and if its hidden or has 0 height then it removes the hidden class from our beautiful message element explaining the situation. The two arguments needed here are the iframe and error message id.

What we need to do next is set a setTimeout function with a delay we think it's adequate to have our page ready.

setTimeout(function() {checkAdBlocker('fake_service', 'error_msg'); }, 1000);

Here is a demo you can check it's functionality. If you have an add blocker enabled you will see a message, if not you will see an iframe with a This is a fake 3d party iframe! text.

This script isn't a solid solution but works for most cases. Is just a first step to help your user not miss a feature in your site, but use it carefully.

Browser History API

2015-10-05T00:00:00+00:00

This is a simple tutorial about using browsers' history API to keep your form selections. Imagine you have a form that filters some posts with ajax. If the user goes to one of those links without opening to another tab, all the filters are going to disappear if he comes back.

This can be easily bypassed with the use of browser history API.

Back to the future I

We 've all used the history.back() back in the old days (and in this example too) to go back to a previous page.

It was awful! Don't do it

If you don't have your own controlled environment e.g a mobile app, you don't know what was the previous page.

Back to the future II

Nowadays we have history.pushState(); that adds a state to the browser history.

This method has three parameters. The state object, the state description and the state url.

State Object: Here you can store an object with things you want to retrieve from this state. A title, some html content and other things tou consider useful. For example, you can store a protion of data to show to the user when he comes back and the retrieve the rest. MDN proposal is a size limit of 640k characters on the serialized representation of a state object.
State Description: You can add a description to your state.
Your state url: This is optional. This changes/is appended to the current url without reloading the page. But if you go to another url and then come back this will be in your url.

I didn't explained all the parameters in depth because we are only going to use the last parameter, the state url.

What we want to do is pass all our form parameters to our url and when we come back we will get these parameters to fill our form.

Here is a live example of what we are going to do.

// Get our elements by id
    var selectBox = document.getElementById('select_value'),
        textBox = document.getElementById('text_value');

    /*
       With every value change in our elements
       we serialize our form (I was to lazy to create a serialize
       function so I used jquery) and send it to the function
       setBrowserHistory();
    */

    textBox.onkeyup = function() {
      setBrowserHistory(serializeForm());
    }

    selectBox.onchange = function() {
      setBrowserHistory(serializeForm());
    }

    /*
       Serialize the form with jQuery (Lazy SOB)
       as a string
    */

    function serializeForm() {
     return $('#form_to_serialize').serialize();
    }

Now we are going to use the history API.

function setBrowserHistory(url) {
    history.pushState(null, null, "?" + url);
  }

As I said before we are only going to use the url parameter and null the other two. We just pushState our url with our parameters with a ? in front of it and that's how magic works.

If you go to another url and then hit back our parameters will be in our url.

This doesn't mean our parameters will be selected in our form. This must be done with some help from your backend. In my demo I just used a function to deserialize the url parameters to show you how it should work.

I hope this was helpful to you!

Laura Kalbag – Ethical Design @ Frontendconf Zürich

2015-10-04T00:00:00+00:00

I always love this kind of talks about the ethical responsibilities we have.

We can make a difference and leave something good behind.

This is a similar talk by Mike Monteiro from Webstock '13 Vimeo link.

BEMIT CSS Based Grid Mixin

2015-09-30T00:00:00+00:00

After reading this article from @csswizardry about taking the BEM naming a step further I wanted to create as simple mixin to build grid classes with this pattern u-1/3@md.

If you 've read any of Harry Roberts' articles, you know that u stands for utility, 1/3 declares that this element takes one third of the available space and @md declares the breakpoint.

Pros:

The CSS and HTML code is highly readable for you and your coworkers
Abstraction/DRY

Cons:

CSS size
Declaration of layout in the dom

I want to say is that I am using this in a project, but this is simple prototype and it needs tuning. I need to come up with an elegant way to add a 'hide this' feature without having to declare it to each grid item because not everyone has the privilege to mess with the backend item loop (if there is any).

This is the (current) sass code to create this kind of grid.

@mixin u-grid-setup($namespace, $width) {

  @media screen and (min-width: $width) {

    @for $i from 1 through $max-cols {

      // If is in the ingore list do nothing
      @if( index($ignore, $i)) {}
      @else {
        $j: 1;

        // Take care of the one col 100% width
        // The `\` character is used to escape characters
        @if $j == 1 and $i == 1 {
          .u-#{$j}\/#{$i}\@#{$namespace} {
              width: percentage($j/$i);
          }
        }

        // Take care of the rest
        @while $j < $i {
          .u-#{$j}\/#{$i}\@#{$namespace} {
              width: percentage($j/$i);
          }

          $j: $j + 1
        }
      }
    }

  }
}

  @for $i from 1 through length($versions) {
    @include u-grid-setup( nth($versions, $i), nth($sizes, $i) + px );
  }

Somewhere in our sass file we need to declare the variables we used in our mixin:

// Set your breakpoints' names and sizes
$versions: "sm", "md", "lg";
$sizes: 320, 768, 1024;

// Set breakpoint unit
$unit: 'px';
// Set you max columns
$max-cols: 12;

// Set columns you want to ignore separated by comma e.g 7,8
$ignore: '';

You don't need to mess with the mixin, you can just declare you variables and compile your files.

You can get a more structured code in my github repository.

If you have any comments or recommendations feel free to comment here or on github.

Vanilla Javascript Selectors

2015-09-25T00:00:00+00:00

Everytime I start a new project I try to evaluate my needs for javascript and decide if I am going to use any third party library or not.

I am not talking about prototyping, we can use everything we want to get a prototype fast and easy, but what about our production code?

I know there are some lightweight javascript libraries out there but trust me, if you 're just using a library to select elements then something is not right.

And it's slower too!

So, this is a post about using your own selectors!

Get Elements By id

This is an easy one, just call document.getElementById('your_id'); and you are ready to go!

// jQuery / Zepto

var element = $('#my_elements_id');

// Vanilla JS

var element = document.getElementById('my_elements_id');

If you think this is boring we can create a simple wrapper function to help our coding.

// Vanilla JS

var element = getById('my_elements_id');

function getById(el_id) {

  return document.getElementById(el_id);

}

Get Elements By Class

Getting elements by class is fairly easy too, but we need to write some code to iterate through the selected elements.

// jQuery / Zepto

var elements = $('.my_elements_class');
elements.text('New Text');

// Vanilla JS

var elements = document.getElementsByClassName('my_elements_class');

for ( var i = 0; i < elements.length; i++ ) {

    elements[i].innerHTML = 'New Text';

}

That's all for now.

Within a few lines of code we saved ourselves a 40kb - 80kb library request and browser memory.

How to Capture User Keystrokes With Vanilla Javascript

2015-09-12T00:00:00+00:00

These days I am in the mood for ditching big libraries and having my own mini libraries or a few lines of code only for using the things I need.

It's not that I don't like the libraries we have, it's that sometimes I just want to have only the things I need for my project.

Why should I map all the keys if I just want two or three of them?

Enough with the developers guilt that loves abstraction layers. Let's proceed with our script.

An example I came accross while I was reading the https://webtypography.net/{:target="_blank"} site — it's great, give it a try — was using keys to navigate through artiles. I know, I am a lazy person, but I miss this when I read tutorials with page sections or a book like site. It's a small script and won't affect the no javascript users.

Let's start by creating a function that captures keystrokes. After we include this in a script, the browser will execute this function for every key press.

document.onkeydown = function (e) {
  console.log('I stroke a key');
};

If you use this function in your document, for every keystroke the browser will log I stroke a key. The e parameter is the event itself that is going to give us the unicode character of the key we pressed.

Now we need to tell this function what to do when a specific key is pressed. In this case we need to map the right and left arrow key to send us to the next page or previous page.

document.onkeydown = function (e) {
  switch (e.keyCode) {
    case 37:
        console.log('Go to the previous page!');
        break;
    case 39:
        console.log('Got to the next page');
        break;

    default:
        return; // Do nothing for the rest
  }
};

And that's it!

You can use whatever key you want without using any library, or create your own lightweight 'plugin' for a number of keys! Here is a list of keycodes from the Toptal{:target="_blank"} website.

Create Custom Description for Your Jekyll Posts

2015-09-07T00:00:00+00:00

There are two ways to create a description from your post, the first one is use the existing post.excerpt tag Jekyll has after reading Jekyll documentation or create your own with some simple steps.

The general idea is to create a custom page variable in your posts and use it in your layouts.

For our example we 'll call our variable post_description, at least that's what I am using for my blog, and give it a value in my markdown post:

layout: post


title: My post title
post_description: This is my post description

---

and in my default.html or any other place I want to use it instead of post.excerpt, now I can use post.post_description and that's it.

You can use these page values anywhere you want. For instance I am using this for creating meta tags for description and keywords in my <head> tag. You can take a peak in my github repository for this site.

You can add and image for your facebook og tags or anything else you can think of.

Update: As Emilio Lopez correctly mentioned in the comments you can declare post_excerpt in the page variables too.

layout: post


title: My post title
excerpt: This is my post description

---

The truth is I prefer extending things than overwriting default environment variables but this is in the Jekyll documentation so, it's safe. (Thanks Emilio!)

Swiper-JW Player

2015-09-05T00:00:00+00:00

Swiper-JW Player is a very small plugin that extends iDangero.us Swiper to avoid setting up the configuration for stopping JW Player videos between slide navigation in each Swiper instance.

This was created to satisfy my need for a fairly abstract/dynamic way to deal with JW Player events, in this case stopping it, without writing code in Swipper callbacks everytime I need something like this.

The goal was to be slide targeted and not just call a jwplayer().stop() that can cause a UX problem by stopping any other player on the page.

Code

(function (Swiper) {

  Swiper.prototype.plugins.jwplayer = function (swiper) {
      'use strict';

      return {
          onSlideChangeStart: function () {

            var jwplayer_elements = swiper.slides[swiper.previousIndex].getElementsByClassName('jwplayer');

            if ( jwplayer_elements.length > 0) {
              for (var i = 0; i < jwplayer_elements.length; i++){
                jwplayer(jwplayer_elements[i].id).stop();
              }
            }

          }
      };
  };

})(Swiper);

How it works

Each time Swiper runs onSlideChangeStart(), this plugin searches for any jwplayer instance in the previous slide and stops it, without messing with the code specified in the configuration for the onSlideChangeStart().

Usage

Just include the swiper.jwplayer.js or swiper.jwplayer.min.js script file in your page after your Swiper script.

Compatibility

JW Player 6, 7

You can download the minified and source code from github https://github.com/codegaze/Swiper-JWPlayer.

VirtualBox Copy/Paste & Drag 'n' Drop

2015-09-01T00:00:00+00:00

You are working with VirtualBox and you want to share clipboard and files between your guest machine and your Linux host?

It's easy...

Or not?

First of all I want to say that I am using VirtualBox 5.0.2 and a Xubuntu 15.04 image, so any problems I have might be a version fault.

Note: Before doing anything, take a snapshot of your machine.

Installing the Guest Additions

In order to enable any interaction between the host and the machine and vise versa we need to install the Guest Additions.

Run sudo apt-get update
Run sudo apt-get upgrade
Run sudo apt-get install dkms
Make some coffee or tea.
Drink it while browsing the internet!
When the installation ends run sudo reboot.
Go to Devices > Insert Guest Additions CD Image
From the opened File Manager copy the path.
Open your console and write cd /path-you-copied/.
Run sudo sh ./VBoxLinuxAdditions.run
Run sudo reboot

Enable communication between Host and Guest

Go to your VirtualBox Manager select your machine and click settings.
From the first selection General, select the Advanced tab and select Bidirectional to Shared Clipboard and Drag 'n' Drop.
Restart your machine.

Create a shared folder

For my configuration drag 'n' drop didn't work in any folder and raised an error which suspended my machine. So I created a shared folder and used this to share any files I wanted.

Go to your VirtualBox Manager select your machine and click settings.
Select Shared Folders and add the folder you want to share between the host and the guest.
Check Auto-mount and Make permanent.
Log off and on again.

Give your user privileges

In order to give your user access to any shared folder run

sudo adduser yourusername vboxsf

Log off and on again. Your shared folders will be in /media/

If I find a anything for the drag 'n' drop part I will make another post or add the solution here. If anyone has a valid solution for this feel free to comment!

Highlight Ruby Code in Jekyll

2015-08-09T00:00:00+00:00

A few days ago I was trying to write a tutorial about creating a simple dynamic menu for Jekyll and I came across a strange problem while I was trying to show and highlight some ruby code.

Instead of ruby code and html I was getting whitespace and html only.

I reinstalled pip and pygments to check if something was wrong with my installation but that wasn't the problem.

After a little research I found out that the problem was that Liquid, the template language Jekyll uses, considered everything inside the curly braces as code to execute.

That thing we call the internet helped me to find out that the solution is another tag called raw.

raw Allows output of Liquid code on a page without being parsed.

That means that if you use the following code(without the spaces between the curly brackets and %) after the highlight tag you can achieve the preferred result.

{ % highlight python % }
{ % raw % }

{ % if page.title == 'Highlight ruby code in Jekyll' % }
You are right!
{ % endif % }

{ % endraw % }
{ % endhighlight % }

results to:

{% raw %}
{% if page.title == 'Highlight ruby code in Jekyll' %}
You are right!
{% endif %}
{% endraw %}

Dynamic Navigation for Jekyll

2015-08-08T00:00:00+00:00

This is a tutorial on how to create a simple dynamic menu for Jekyll.

Jekyll is great for static sites, but if you are lazy like me you want to add some scripts here and there to make your life easier.

Jekyll uses the _data folder to create dynamic data with the use of .yml files. You can name the file however you want but keep in mind that we are going to use it to retrieve the data with site.data.filename.

First of all you need to check if there is a _data folder in your project folder. If not we must create it and add a navigation.yml file in with this data:

- title: Home
  url: /
- title: Blog
  url: /blog/
- title: About
  url: /about/

Next add this script to your default.html in your _layout folder or create a menu.html file in your _include folder.

{% raw %}

<nav>
    <ul>
    {% for link in site.data.navigation %}
        {% assign current = nil %}
        {% if page.url contains link.url %}
            {% assign current = 'active' %}
        {% endif %}
        <li class="{{ current }}">
            <a href="{{ link.url }}">{{ link.title }}</a>
        </li>
    {% endfor %}
    </ul>
</nav>
{% endraw %}

The latter is better and you need to include the menu in your preferred place in your default.html

{% raw %}
{% include menu.html %}
{% endraw %}

Refresh your page and see your new menu!