I started a newsletter in January. It is called Rado's Tips.

You can check and subscribe at 👉 https://tips.rstankov.com 😇

I'll be sharing with you tips and stories. You can expect topics around software engineering, product development, management, productivity, and ... everything else that comes to my mind. 🚀

If you have any questions or comments, you can ping me on Threads, LinkedIn, Mastodon or Twitter. 📭

Recently, I noticed a lot of features in Angry Building have the following pattern:

1. I go to the Rails console in production and do some operation
2. I copy the code, which I executed in the Rails console, into a file wrapped in a function, which I can copy/paste into the console.
3. Move the function into a service object in the main codebase, cover it with tests, and handle all edge cases.
4. Wrap service object with form object and expose it with web form only to admin users
5. Expose the form to users - this operation was battle-tested by this time, and we know all of it has implications.

Example

One example of such a feature is our change of payment's apartment.

In Angry Building, we track tax payments made by the apartment to the facility.

We allow importing payments from bank transfers, where we create payment records for apartments based on bank transfers.

For some transactions, we determine which apartment has made the payment. Then an operator can assign the apartment manually. Mistakes can happen here, and we need to re-assign the apartment.

Over time, as we get more customers using this feature, we get more requests for change payment apartments.

So change the payment apartment feature following the 1 -> 5 steps to be implemented.

Discussion

Now, I know what you are thinking - Why don't you just go to the 4 or 5 (implement in UI) steps, why spread work around? ?

Some features go to the 4 or 5 steps directly. It is a judgment call.

If I had to implement UI and expose everything I had to do in the console, my software would be bloated, and I would need a bigger team.

Many "features" fizzle out in steps 1 or 2 (execute directly in the production console) are caused by bugs or confusing UI.

When I get a request that requires me to go to the console - I try to do a root cause analysis to see how to prevent this. I have increased the overall system quality so much because of this.

When we reach step 3 (move to code as service object covered by tests), the threshold to become "a real" feature is passed. Then moving to step 4/5 is more about work priority and how dangerous it is to expose this feature to everyone.

Then is more about how often we get the request to call this service object.

The features implemented this way are based on support requests. Not all features go through those steps.

If you have any questions or comments, you can ping me on LinkedIn, Mastodon or Twitter.

When I was younger, I was often told - "Luck is quality". I hadn't put much thought into it back then. It sounded cool and helped me gather the courage to leave my comfort zone. Later in life, I realized I was right. "Luck is quality" Here is why I think so.

Let's break down the concept of luck. What is it? In my view, luck is a blend of two crucial components:

1. Opportunity
2. Ability to convert that opportunity into a success

"Luck" is compounding. The more successful you are, the more opportunities arrive, and you gain more skills and abilities to take advantage of those.

So, how do we become "lucky"?

1. Step out of your comfort zone. Luck rarely comes knocking at your door while you're sitting at home. It is found in the field, amidst the hustle and bustle of life, in the effort of pushing boundaries and exploring new horizons.
2. Educate yourself. Luck favors the prepared mind. Cultivate specific knowledge and skills pertinent to your goals. This will increase your odds of recognizing and seizing opportunities when they arise.

The risk lies in assuming invincibility amidst a streak of successes. One might start to believe that their good fortune is limitless or that they've mastered all there is. They may overlook the need to enhance their skills and adapt to the evolving dynamics of their field.

(I'd recommend reading "What Got You Here Won't Get You There" ? and "Quit" ? on this subject)

So, what should you do when you're on a roll?

1. Seize more opportunities. Luck breeds luck. Use your existing momentum to explore further avenues for growth and success.
2. Pay It Forward. Extend your support to others, fostering a culture of shared success and mutual growth.
3. Exercise caution. Balance is key. Avoid overextending yourself. Don't mistake luck for skills. Keep these tips in mind:
   • Steer clear of illegal or immoral actions.
   • Dodge actions that might lead to bankruptcy.
   • Avoid actions you'd be ashamed to share with a trusted friend.
   • Resist believing that things will work out without effort.
   • And lastly, guard against envy which leads to status games and greed.

Remember, luck is not a mystical force that arbitrarily blesses some while overlooking others. Instead, it's a product of hard work, skill, and an opportunistic mindset. So go ahead, make your luck, and create a path toward success.

If you have any questions or comments, you can ping me on LinkedIn, Mastodon or Twitter.

Ruby on Rails Engines is one of the most powerful and underestimated features. It distinguishes Rails from other web frameworks.

What engines?

Engines are embeddable applications that can be integrated into your Ruby on Rails application. They are distributed as regular Ruby gems with models, controllers, and views.

The UI that comes with engines is incredibly useful, and most engines can be set up within 10 minutes, saving months of integration of microservices and external SaaS tools.

Here are the top eight Ruby on Rails engines:

1. Sidekiq - background jobs
2. Blazer - business intelligence
3. Lookbook - UI components previews
4. Flipper - Feature toggles
5. Split - A/B testing
6. PGHero - PostgreSQL monitoring
7. FastEntry - cache previewer
8. GraphiQL - GraphQL IDE

1) Sidekiq

Sidekiq is the de facto standard for background jobs in Ruby land. The engine provides a UI to monitor what is happening with your background jobs.

2) Blazer

Blazer allows you to write SQL queries and build charts and dashboards from them, making it an excellent tool for business intelligence.

But even if you don't use it as a business intelligence tool. It is a great developer tool. It can help you see what is in your database in local or staging environments.

3) Lookbook

I found this recently.

If you use ViewComponents to build UI elements instead of Action View Helpers, you should use it. It builds on top of previews and wraps them in Storybook like interface.

However, if you have ever tried to set up Storybook and React components, you have spent A LOT of time on it.

This gem takes about 10 minutes to set up, and the rest is just writing simple previews Ruby classes.

4) Flipper

Flipper provides infrastructure and UI for Feature toggle.

I have written before how to integrate with React - here.

Flipper has a paid version with features like permissions and audit history.

5) Split

Split provides infrastructure for A/B testing.

There are a lot of SaaS tools to do so; however, they are slowing your pages, cost a lot and take time integrate.

6) PGHero

It provides a performance dashboard PostgreSQL. It tells you things like - slow queries, unused indexes, table/index sizes, and more.

It comes from ? Instacard, which makes also Blazer and other wonderful open source projects.

7) FastEntry

Do you know what is in your cache? FastEntry shows you this. Simple and useful.

I have found a secondary use for it in development. I use the same Redis instance for cache, Sidekiq, and application data storage. It shows you everything in this Redis instance.

8) GraphiQL

Last but not least. GraphiQL is IDE for GraphQL. This engine provides quick setup and integration.

How to setup and secure engines?

I mentioned that engines are easy to set up. But talk is cheap. Let me show you the code. ?

Let's install Blazer, as it is one of the more complex ones to set up.

Step 1: Add to Gemfile

gem "blazer"

Step 2: Bundle install & database setup

bundle install

rails generate blazer:install
rails db:migrate

Step 3: Mount to the Rails application

# config/routes.rb
namespace :dev, constraints: Routes::AdminConstraint do
  mount Blazer::Engine, at: '/blazer'
  # ... other engines
end

Note: Routes::AdminConstraint ensures that this namespace is only available for certain users.

A simplified version can look something like:

module Routes::AdminConstraint
  extend self

  def matches?(request)
    return false if request.session[:user_id].blank?

    User.find(request.session[:user_id]).admin?
  end
end

In Production: Have database as ENV variable

ENV["BLAZER_DATABASE_URL"] = "postgres://user:password@hostname:5432/database"

That's it, you have a business intelligence tool ?

Conclusion

Engines have saved me a lot of time (and use of external services) over the years. I'm constantly on the lookup for new useful ones ?

If you have any questions or comments, you can ping me on Twitter or Mastodon.

A good way for developers to level up is, instead of reading the same beginner tutorials on sites like Medium and blogs, to read documentation and source code of libraries they use.

I often open the source of code of Ruby on Rails, RSpec and React.

Recently, I have been reading Mastodon and React-Flow.

What will one gaining by doing so?

1. Learn to read code. Most of the time, developers are not writing code.- they are reading.
2. Learn techniques in the real world. Books and blog posts often give us simplified version it is more understandable. Real life is messy.
3. Find out about useful helpers in those libraries. For example, even today, I found an about a new Rails-RSpec matcher built years ago. This will save me a lot of time in the future.
4. Understand everything is built by other humans. This one is more meta. So often, I see junior developers take for granted that library works this way.
5. Debugging. I can't recall how often I had to dive deep into the library source code to trace a weird behavior in our system.

Personal story

This was around 2005 or 2006. Back then, I was trying to learn JavaScript. Every piece of JavaScript code seemed to me like magic.
The first time I had "I got it and now understand what this is doing" was when I was reading the source code of Prototype.JS. This was while reading some "prototype" and "DOM" code. I can still recall the joy I felt at this moment. ?

One common problem in project management is managing bugs. Over the last couple of years at Product Hunt, we have used the Bug Duty process to handle and deal with upcoming bugs.

This process handles the following problems:

• Where do you put bug fixes in a sprint
• People reaching to their friend engineer to do their pet fixes or features

It also has the following benefits:

• Helps engineers to know the codebase better
  • It is great for onboarding new team members
• Improve skills by helping engineers to learn how to
  • Manage a project board
  • Debug tricky code
  • Get better at avoiding known bugs
• Provides a pipeline where people across the company can provide feature ideas

Bug Duty process

A different person from engineering is assigned to the Bug Duty sprint every sprint. During this sprint, they don't work on a project. Instead, they work on "Bugs" project in Asana.

The engineer has the following responsibilities:

• Manage the "Bugs" project in Asana
  • Fix outstanding bugs
  • Immediately fix the bugs marked as "high priority"
• Attend the Support team weekly sync, where issues with our website are often discussed
• Be available in the #product-feedback Slack channel
  • Our teammates post issues there. The person on bug duty should handle those
• Handle all upcoming exceptions reported in #engineering-sentry
  • This Slack channel receives all Sentry errors. We try to keep their number to 0 in production.

The goal is for them not to do the following ?

The process is simple Collect -> Triage -> Group and Handle:

Report a bug form

Bugs are reported via Asana Form and get into the "Bugs" project. The goal is to get enough information for debugging.

Asana Project

We use Asana for project management. The "Bugs" project looks like the following:

Here is what each section means:

• "Just reported" - Where reported bugs arrive. They should be handled during the day.
• "QA reported" - We use the external agency Lodestone for QA. They do a lot of exploratory testing and report bugs in this column
• "Bugs" - Those are known and triaged bugs from "Just reported"
• "Next up" - Bugs to be fixed next
• "In progress " - In-progress fixes
• "In review" - Fix is ready, now it's in code review
• "Awaiting confirmation" - Waiting for a bug fix to be confirmed by QA or the person who reported
• "Fixed" - List of fixed bugs
• "Won't fix" - These are either not bugs, or bugs that won't be fixed
• "Feature suggestions" - Feature ideas collected from the team. PMs look through those to add to various projects backlogs

First day

When someone starts their bug duty

• They should assign themselves as project owner of the "Bugs" project
• They should assign themselves to the #product-feedback Slack channel
• Talk with the person previously on bug duty
• Check the status of in-progress bugs
• Check all existing bugs

Last day

Follow the Scout Rule - leave the project in better shape than you found it.

1. Make sure to close all ongoing things they are working on.
2. Unassign from tasks and move out of "Next up".
3. Talk with the next person on Bug Duty about any urgent and important bugs you think will make sense for them to work on next.
4. Do a retrospective about how you did this bug duty.
   • What were common issues you faced?
   • How can we improve our code or Bug Duty process?

Schedule

We keep the schedule of who is on bug duty on Notion. It is negotiated between team leads which should be on bug duty

Failure modes

There are a couple of failure modes we have faced.

"There are too many for a single person to handle"

We were in this situation once, after multiple migrations and redesigns. We made a "Bug Bash" sprint when everyone was on fixing bugs and gave out Golden Kitty awards to the people who reported and fixed most bugs.

"I don't understand this area of the system enough to fix the issue"

This happens often. The solution is to find someone who knows this area and do pairing programming sessions to fix the issue.

"Engineer on bug duty slacks and don't take on important bugs"

It is up to their team lead to monitor their performance. Having more formalized handoff/retro can also help with this.

"We don't have enough engineers. So none can be spared to be on bug duty."

This is a resources and planning problem. We solve this by using Bug Duty for onboarding or some team leads standing in on Bug Duty.

Conclusion

We have tweaked and adjusted this process over the last couple of years. It helped us keep our system clean of bugs ?

If you have any questions or comments, you can ping me on Twitter .

Last year we very eventful for Product Hunt. On technical level we closed large system migrations like fully switch to Next.js for frontend, moved to TypeScript and rewrote our mobile app with React.Native.

Here is how our technical architecture looks currently:

I have given detail talks about each section of our systems.

• Backend - Rails, GraphQL, AWS, Docker, PostgreSQL (slides , video)
• Frontend - React, TypeScript, Next.js, Apollo (slides , video)
• Mobile - React Native, TypeScript, Apollo (slides, video)

Here is what a web request goes through to deliver a page from the site:

Overall, I'm very happy with our current system. It allows us to handle our traffic and ship fast and reliable.

Whats comes next?

Software is never done and this is true for us. We already had started improving on our foundations like:

• better core React components
• kinda, moving towards Domain Driven Design.
• improving on backend infrastructure for better performance and monitoring

For any questions or comments, you can ping me on Twitter.

In two of my most popular blog posts - "Collaborative Single Player Mode" and "Feature Planning", I mentioned one of my coding principles:

Write code as if you are going to remove it tomorrow.

I get a lot of questions about this. What do I mean by that?

When you write code for a new feature, you want it to be decoupled from other parts of your system. Put it in its own bucket - namespace, module, directory, etc. (depending on the technology). This makes the code easier to test and reduces the risk it will break existing functionality.

I have found that a good way to tell how decoupled some code is to find out how much work it would be to remove the feature it is powering. If removing a feature is just remove a folder + 2~3 integration points - that's good code.

Because of this, I prefer to organize code based on domain than on type.

But how often you remove features? ?

At Product Hunt, we do this quite often ? , and this is a good thing. When you do product development, you discover what works and what doesn't via experimentation.

But I spent so much work on this feature, and now my work goes to waste? ?

Not really. On the product level, you learned something, and hopefully, this will give you a better direction for future work.

Product logic gets simpler. Think about losing body fat.

But I had some really, really cool code there? ?

When I write code, I make a clear distinction between Plumbing vs. Domain. I have found that plumbing utilities are often where the "elegant" and "cool" code is.

This often happens to me. I build a feature and separate its plumbing utilities and domain. Then, for another feature, either me or a teammate use the utilities. Later, the original feature is removed, and the utilities stay.

If utilities are isolated, they are often re-used in different domains. So this cool code stays after the feature.

For any questions or comments, you can ping me on Twitter.

A year ago during the first COVID-19 lockdown, I started working on a small macOS menubar app called ? FocusedTask. I used Electron, React and Redux and it is open source.

When I work on a task, I usually need 3 things - a quick list of nested todos, a list of links related to my task, and an area to scribble notes

Last year, I was switching between a pinned note in Bear and projects in Todoist.

I'm a big fan of macOS menu bar apps and shortcuts, so I decided to combine those two and build FocusedTask.

After just 2 days of coding, I was able to start using it.

The hardest part of the app was to get a paid Apple developer account (they didn't like my Bulgarian debit card) and making the notarizing to work. ?‍♂️

I still use Bear and Todoist for other parts of my workflow.

I launched the app on Product Hunt with moderate success.

According to my logs, currently, 29 people use the app daily, which makes me very happy ?

I got a couple of contributions to it:

• UI/UX improvements from Vestimir
• Dark theme, settings, and more shortcuts from TJHdev

I have given a couple of talks about the code structure of Focused Task

Conclusion

I don't have any grandiose plans for FocusedTask. It is just a small tool I built for myself. I learned a lot while making it.

I'm very happy that other people use it too.

It is a win in my book. ?

You can download it from ? here or check its source.

For any questions or comments, you can ping me on Twitter.

Next.js is an excellent tool. I see it as Ruby on Rails for React.

I have been using Next as starting point for React applications for about 3 years. Last December, me and my team were able to migrate Product Hunt to Next.

Here are some of the techniques I use to structure Next applications:

1. Keep screens out of page folder
2. Wrap Next's Link component
3. Have a paths helper to generate links
4. Build each page via a createPage helper

Technique 1: Keep screens out of the pages folder

Next uses a file-based router. It is lightweight and gives you a good overview of your pages. However, pages tend to have many "private" components, which you want to keep near the page code. Also, the URL structure of your application is often different than the domain structure.

Because of this, I use the following directory structure:

~/components/
~/screens/
~/pages/

pages is the Next router. Files there are just imports of components from screens.

// ~/pages/posts/[id].ts
import page from '~/screens/posts/show'

export default page;

screens is where the actual pages live. They are grouped by domain. Everything in this folder is considered "private" and can't be imported from the outside.

~/screens/posts/show/index.tsx - entry point of screen
~/screens/posts/show/Query.graphql - query to fetch the data
~/screens/posts/show/utils.ts - helper functions
~/screens/posts/show/PrivateComponent1.ts - some "private" component
~/screens/posts/show/PrivateComponent2.ts - other "private" component

All reusable components are in components. My definition of "reusable" is "used at least in two places".

Here you can read more about structuring components in general.

Technique 2: Wrap Next's Link component

Every routing library has a Link component. It is used instead of the <a> tag. When clicked, it changes the URL without a full page redirect, and then the routing handles loading and displaying the new page.

I always wrap the routing library Link with my own Link component.

Next's Link component interface is a bit different than that of the others, but it functions in the same way:

<Link href="/company">
  <a>Company</a>
</Link>

I don't like that there are two components here - it is too cumbersome for my taste. This alone is a reason enough to wrap it.

Wrapping it also makes it easier to migrate to something like Remix or Gatsby, if needed.

Here is my wrapped Link:

import * as React from 'react';
import Link from 'next/link';

// support both static and dynamic paths
type IPath = string | { as: string; href: string };

// allow this component to accept all properties of an "a" tag
interface IProps extends React.AnchorHTMLAttributes<HTMLAnchorElement> {
  to: IPath;
  prefetch?: boolean
  // ... more props we want to pass to Next Link
}

// Overwrite, Next default prefetch
export default React.forwardRef(({ to, prefetch = false, ...props }: IProps, ref: any) => {
  if (typeof to === 'string') {
    return (
      <Link href={to} prefetch={prefetch}>
        <a {...props} ref={ref} />
      </Link>
    );
  }
	 
  return (
    <Link href={to.href} as={to.as} prefetch={prefetch}>
      <a {...props} ref={ref} />
    </Link>
  );
});

Notice how I have overwritten the default prefetch value. Having our Link component allows us to do things like this.

Having such a wrapper was very useful the two times Next changed how they handle dynamic routes.

Technique 3: Have a paths helper to generate links

People often use hardcoded links in React applications:

<Link to="/about">About</Link>
<Link to="/contact">Contact</Link>
<Link to={{ href: '/post/[id], as: '/post/1' }}>Post 1</Link>

This is brittle, not type-safe, and makes renaming URLs or changing URL structure hard.

I have solved this by having a paths.ts file that defines all routes in my apps:

export default {
  about: '/about',
  contact: '/contact',
  post: ({ id }: { id: string }) => { href: '/post/[id], as: `/post/${id}` }
}

This way, I can change the routes, and I’m protected from typos.

import paths from '~/paths';

<Link to={paths.about}>About</Link>
<Link to={paths.contact}>Contact</Link>
<Link to={paths.post(1)}>Post 1</Link>

Technique 4: createPage

Every page entry uses the createPage helper. It handles the basics each page requires - data fetching, error handling, SEO tags, permissions, layout, etc.

// components/Component/index.js
import QUERY from './Query';
import { SomePage as IData } from 'graph/SomePage';

// 1) Create page as a default export
// makes it easy to quickly see the page options
export default createPage<IData>({
  // 2) Lead with Query
  query: QUERY,
  queryVariable: ({ id }) => ({ id });

  // 3) What are the page requirements
  requireLogin: 'edit post',
  requireAdmin: true,
  requireFeature: 'new-edit-page',
  requirePermissions: ({ post }) => post.canEdit,

  // 4) Rest of the options
  layout: PostLayout,

  bodyClassName: 'white-background',

  setTags: ({ post }) => post.meta,
  setStructuredData: ({ post }) => post.structuredData,

  // 5) the Page's main component
  renderComponent({ data }) {
    // render the page
  }
});

Conclusion

I had used those techniques before Next existed. They help me to keep the whole system decoupled and make it obvious what is used where.

Because of this, my team and I migrated Product Hunt (a 7-year-old codebase) to Next in about a month.

I hope you find them useful as well. For any questions or comments, you can ping me on Twitter.

In my blog post about Feature Planning, I omitted an important thing I do while developing. I split the feature work into plumbing and domain.

Domain: User, Post, FounderClub, Comments
Plumbing: Handle::RaceCondition, Formatter, KittyEvents, SearchObject

I define plumbing as the infrastructure code needed to enable the business logic/rules.

Domain logic is connected to the business and changes as often as the business does. It is more connected to the real world. Changes come from "outside", not from developers.

On the other hand, plumbing is in the developer's "land". It is all the utilities we have in the system that defines the underlining rules of the systems. I tend to find it more stable and, thus, more comfortable to generalize.

An excellent example of this is Ruby on Rails, it is the extracted plumbing of Basecamp. Recently, they also extracted the Hotwite library, which is the plumbing around their new app Hey.

In Product Hunt, we often remove features. What we keep is all the plumbing we build for them, which makes our system better.

Conclusion

When we work on a feature, there are two types of things we usually do - plumbing and domain.

A domain is defined by business rules and changes often. Plumbing is the utilities we use to build our system. Those can be more generic and used in various places in our system. I call those "code improvements". The rules for making a good domain and plumbing code are different.

While doing some work on the Product Hunt stories page, I noticed that the page was performing too many SQL queries. The page itself is quite simple.

The following is the React structure of the page:

<Header>
	<Flex.Row>
		<Image>
		<Flex.Column>
			<Title />
			<Meta />
			<Tagline />
			<StoryVoteButton showVoters={true} />
		</Flex.Column>
	</Flex.Row>
</Header>
<Layout>
	<Layout.Content>
		<StoryItem>
			<Flex.Row>
				<Flex.Column>
					<Title />
					<Meta />
					<StoryVoteButton showVoters={false} />
					<Tagline />
				</Flex.Column>
				<Image>
			</Flex.Row>
		</StoryItem>
	</Layout.Content>
	<Layout.Sidebar />
</Layout>

For the page we have the following GraphQL query:

#import "~/components/StoryHero/Fragment.graphql"
#import "~/components/StoryItem/Fragment.graphql"

query StoriesIndexPage($cursor: String) {
  heroStory: stories(first: 1) {
    edges {
      node {
        id
        ...StoryHeroFragment
      }
    }
  }

  stories(first: 8, after: $cursor) {
    edges {
      node {
        id
        ...StoryItemFragment
      }
    }
    pageInfo {
      endCursor
      hasNextPage
    }
  }
}

After some debugging, I figure out the issue is the StoryVoteButton. It was making N+1 queries to load the voters of story items.

The vote button was using the following GraphQL Fragment

# FILE: ~/components/StoryVoteButton/Fragment.graphql
#import "~/components/UserImage/Fragment.graphql"

fragment StoryVoteButtonFragment on Story {
  id
  hasVoted
  votesCount
  voters(first: 6) {
    edges {
      node {
        id
        ...UserImage
      }
    }
  }
}

Notice that it loads the voters of the story. It is quite expensive, because:

• the connection edge doesn't batch load voters due to pagination
• the voters query is expensive due to complex order conditions like showing current user friends first, then popular users, and so.

The button had two variants with and without voters:

Showing voters was controlled by a prop named showVoters:

<StoryVoteButton story={story} showVoters={true} />
<StoryVoteButton story={story} showVoters={false} />

When showVoters is false, we don't need voters. However, we still load them. We only need them once on a page, so we over-fetch most of the time.

Fix 1

My first fix took me just 15 minutes.

I just created a second fragment, FragmentWithVoters.graphql, and let the component consumers use it when they pass showVoters={true}. This fragment included the voters.

# FILE: "~/components/StoryVoteButton/Fragment.graphql"
fragment StoryVoteButtonFragment on Story {
  id
  hasVoted
  votesCount
}

# FILE: "~/components/StoryVoteButton/FragmentWithVoters.graphql"
#import "~/components/StoryVoteButton/Fragment.graphql"
#import "~/components/UserImage/Fragment.graphql"

fragment StoryVoteButtonWithVotersFragment on Story {
  id
  voters(first: 6) {
    edges {
      node {
        id
        ...UserImage
      }
    }
  }
  ...StoryVoteButtonFragment
}

It was nice and easy.

Job well done ... ?

...then, while I was doing a self-code-review, I realized that this makes the code more complex.

The consumer has to know that a property requires a particular fragment and use it instead of the default one. This distinction isn't obvious. ?

Those thoughts helped me realize and I had broken this button on the stories show page. ?

Fix 2

I moved my pull request into a "work in progress" state and started refactoring.

I decided to split StoryVoteButton into:

1. StoryVoteButton - loads only counters

2. StoryVoteButtonWithVoters - StoryVoteButton + story voters

Conclusion

Moral of the story: Alway do a self-code-review as if you didn't write this code ?

Secondary learning is that in React, sometimes props are just hidden components, and we shouldn't push too much logic in a single component. Better to have two components. ?

I've been keeping a personal journal for about 7 years now. Four months ago, I decided to start a dedicated "Manager Journal" to keep track of my work at Product Hunt. It helps me quite a bit in navigating the big company changes and the team growth we've had in the last couple of months.

Process

I have a pinned note in Bear and fill it in with data during the week.

Every Friday:

• Send my weekly feedback to my direct reports
• Write in our #engineering Slack channel to recap all the "Code improvements" done by the team
  • (as the PH team grows, this might become an internal newsletter)

Every Sunday:

• Review what happened during the week
• Archive and reset the contents of the note
• Plan for the next week

Template

I've been using this template since the beginning of November. I still tweak things here and there, but it has been fairly stable for a while now.

# ? Product Hunt Week

Start: 00/00/2021
End: 00/00/2021

## ? What I did last week
* [copied from "What I worked on this week" from last week"]

## ? What I plan to work on week
* [what I expect to work this week]

## ✅ What I worked on this week
* [what I actually worked on this week]

## ⛑ Concerns
* 

## ? Code improvements
*  

## ? Notable events
* 

## ? Team feedback

### Me
* Good: 
* To improve:
* Observation: 

### [Teammate 1]
* Good: 
* To improve:
* Observation: 

### [Teammate 2]
* Good: 
* To improve:
* Observation: 

Details

Let's get into some details about this format. ?

The first 3 sections - "last week", "planned this week", "done this week" help me focus on what to work on during the week, what I have committed to, and what I did in reality.

The items in the list are very high level. Like "Hiring", "Improve CI performance", "Audit our post scheduling system."

Keeping last week visible also helps me notice initiatives spanning multiple weeks or things that I'm stuck on.

"⛑ Concerns" is where I write about all my worries during the week. I got fairly good at recognizing when I'm anxious about something.

Examples are "Project X is late", "Public API performance is dropping", "People are confused about X process change", "We don't have good enough tools for e2e tests".

I often use those as a starting point for new initiatives and addressing core issues. Often, just writing those down makes me feel better.

" ? Code improvements" is the log of small system improvements done during the week by my team.

One of my team's core values is constant self-improvement. As part of the daily work, every engineer is nudged to extend our system while working on various features.

Those improvements can be small like "extract a new utility for number formatting" or bigger like "changed moment.js to date-fns". We have a special section in our Pull Request template to list such changes.

Every Friday, I share those with the whole team. It has the following benefits:

• Not everyone keeps track of those changes, and it is useful to know
• Shows how much progress we have made in the week
• It is a positive reinforcement of team values

"? Notable events" is a fairly new section. It is still in the "testing phase" for stuff not applicable in the other sections. Like "X launched on PH, and this lead to a lot of traffic from Y", "We launched Y feature", "The company switched from Trell to Asana"

"? Team feedback" is the section this document actually started from.

I keep a log for everyone in my team, including me.

I have 3 sections there - "Good", "To improve" and "Observation".

I'm a big user of positive reinforcement because it is easy for people to continue doing things they are already doing.

For "To improve.", I try to focus on "action -> outcome" and how it could have been done better. Often this is a discussion.

"Observations" are neutral or fun things I notice during the week.

I share this feedback with my team, and feedback tends to be small and actionable. (I have a draft post about giving feedback)

It helps me spot behavior patterns, positive and negative, which I can later discuss in my monthly 1on1s.

I keep the feedback from myself, which comes from my team or observations about things I could have done better. It is surprisingly helpful.

Example - "I'm not clear enough with my requirements to the DevOps. For 3 weeks in a row, I've been getting some questions about naming and environment variables."

Conclusion

When working, it is far too easy to focus on daily activities and lose track. The "Manager Journal" helps me keep track of my week and helps me spot patterns across multiple weeks. It is almost passing the habit threshold for me.
If you have any questions or comments, you can ping me on Twitter.

Last year the whole world was forced to switch to working from home. It was an acceleration of the trend of working remotely. One of the most common questions managers ask when this switch happened: "How can I know my people are working". A lot of them have the wrong (in my opinion) assumption that:

1. If you are in the office, you are working
2. People are always searching for a way not to work.

"Are people working" is the wrong question. The right question is, "are we delivering" and "are we working on the right thing". I don't care if the engineers on my team only work 1-2 hours a day, as long as they deliver.

In an office environment, we are often blinded by the input we see - for example, "Rado is always in front of his laptop, he must be working a lot". Even worse, if someone is very "loud" during standups and meetings - they must be very knowledgeable.

The usual advice people give is to "Measure output, not input".

However, this isn't very actionable. What is the output? What is the correct output? Do I get the output of an individual or a team?

Pre-conditions

I have found out that to measure the output of a team, you need the following pre-conditions:

• Have an anchor or baseline
• Create a rhythm of work for everyone - all sprints start and finish on the same date.
• Have clear expectations about the expected output
• Enable people to work independently by removing blockers and dependencies between people (collaborative single-player mode)

Not having clear expectations is easier to hide when you're in the same office because people assume other people know the context.

How this currently works at Product Hunt

In Product Hunt, people are grouped into teams, and they work in 2-week sprints. Every team sprint starts and ends at the same time. This creates a rhythm of work.

Tasks in the sprint are split in such a way that developers can work in single-player mode.

We encourage people to open pull-requests and deploy to production every 1~2 days with feature flags. A single task can have 2-3 or more pull-requests.

We have weekly check-in on sprint progress - is it on track or not.

With this process, it is easy to spot if a task is stuck and possible to quickly correct course. I have very rarely seen cases where someone is not working. Usually, the task is stuck because of a scope issue or technology challenge.

Overwork

What I have often seen in a remote environment is people overworking. Because I don't know if someone works 2 hours or 12, it is easy to hide overwork. This makes it difficult for this individual to set the right expectations and it hides problems with task scoping.

The way to solve this is to trust the team. Don't blame people when they are late, and don't award people who overwork.

I often say:

It is not a problem to be late. A problem is - not telling me you will be late the moment you realize it.

Conclusion

I have been working remotely for about a decade, and I can't see myself ever measuring people's hours. I care that people don't do many extra hours, though, because this is unhealthy and stems from bad planning.

Being in an office often hides problems with the process. You need 10x more process for remote sensing initially, but, with time, it scales better than being at the same place.

If you have any questions or comments, you can ping me on Twitter.

I've been using React since 2016. React has changed a lot since then, but the fundamentals have stayed the same.

In the last couple of years, the Product Hunt team and I have settled on a way to structure our components.

The goal is to make understanding components easier.

Every component should provide quick answers to the following questions.

• What are the props this component needs?
• What does this component do?
• What are the component's states?
• What is the component's logic?
• How can we trace the logic?
• Is it easy to refactor?

Component as directory

Components are encapsulated in directories that contain their individual parts.

The only public thing there is the main index file.
Everything else is considered private.

Here is what the component directory looks like:

~/components/[Component]/index.tsx                // default export is the used component
~/components/[Component]/Fragment.graphql         // GraphQL fragment for the component
~/components/[Component]/Mutation.graphql         // GraphQL mutation for the component
~/components/[Component]/styles.module.css        // css-module, with styles for the component
~/components/[Component]/[icon].svg               // icon asset
~/components/[Component]/utils.ts                 // helper functions/classes for the component
~/components/[Component]/utils.test.ts            // tests for helper functions/classes
~/components/[Component]/[SubComponent]/index.tsx // when this component is complex, it's might
~/components/[Component]/[SubComponent]/...       // be split it into multiple components
~/components/[Component]/[SubComponent]/...       // they are private and shouldn't be imported
~/components/[Component]/[SubComponent]/...       //  from outside its parent component

Component

Every component we have, has an entry point like the following:

// components/Component/index.js

// 1) Component props
// always name this "IProps"
// this makes it easy to quickly see the expected props for this component
interface IProps {
  // ...
};

// 2) Main component export
// immediately after, put the component name since this is what this package is all about
// use default function values for default props
export default function ComponentName({ prop1, prop2 = 'default value' }: IProps) {
  // component is structured by
  // 2.1) Hooks
  // if this is more than 5 lines, a custom hook is extracted
  // more about this - https://blog.rstankov.com/extract-react-hook-refactoring/

  // 2.2) Guard clauses
  if (someCondition) {
    return null;
  } 

  if (someOtherCondiation) {
    return <SamePlaholder />
  }

  // 2.3) The happy path of the component
	return <div>My component</div>;
}

// 3) Everything else...
// Here's where the smaller helper hooks, utils, and components live.
// If those get bigger, they can be moved into separate files in the component directory

This structure makes it very easy to scan component and find what you are looking for.

Conclusion

This structure has served us well, and its fundamentals have stayed the same when migrating from classes to hooks, from flow type to TypeScript, and so.

If you have any questions or comments, you can ping me on Twitter.