Forem: Sophia Brandt

TIL: Insert Macros for the Helix Editor

Sophia Brandt — Wed, 26 Jul 2023 19:30:00 +0000

I’ve been using the Helix editor for two weeks now as my daily driver in my personal coding projects.

Helix is a modern terminal text editor that’s quite capable as a tool for writing code.

A Kakoune / Neovim inspired editor, written in Rust.

Features

Vim-like modal editing

Multiple selections

Built-in language server support

Smart, incremental syntax highlighting and code editing via tree-sitter

After some initial bumps in the road due to my Vim muscle memory, I have grown quite fond of Helix. For my pet projects (TypeScript) it works well.

The language server support is great. It offers me the convenience I am used to from other editors (IntelliJ) - auto-complete functionality, hover information and so forth.

Helix is not a fully-fledged IDE, but it doesn’t aim to be one. It is supposed to be an alternative to Kakoune or Vim/NeoVim.

Insert Macros

My NeoVim config sports an “insert macro” for the fat arrow (=>). When I type ‘hsr’ in insert mode, the editor automatically replaces these three characters with a fat arrow (hashrocket).

Here is how the key mapping looks in Vim:

# custom/keymappings.vim
inoremap hsr =>

And the same config in lua (NeoVim):

vim.api.nvim_set_keymap('i', 'hsr', '=>', { silent = true, noremap = true }),

This can also be achieved in Helix:

# ~/.config/helix/config.toml
h = { s = { r = ["normal_mode", ":insert-output echo '=>'", "collapse_selection", "insert_at_line_end"] } }

Keyoxide Proof

Sophia Brandt — Wed, 09 Nov 2022 14:32:38 +0000

[Verifying my keyoxide cryptographic key: https://keyoxide.org/4C38CC1AF264C3DE8D6D97283B31E6D41B517DA5]

Notes on “Building a Pragmatic Unit Test Suite”

Sophia Brandt — Sun, 06 Nov 2022 20:55:00 +0000

Here are some notes on the course “Building a Pragmatic Unit Test Suite” by Vladimir Khorikov.

Goals and Guidelines

Unit tests help with confidence: you know that changes don't break functionality.

Not all unit tests are equal.

Coverage metrics are problematic: you can work around them, for example, by writing assertion-free unit tests.

Coverage metrics are a good negative indicator, but 100% test coverage is impractical.

Test are code, and you also have to pay a maintenance cost for your tests.

What makes a unit test valuable?

carefully choose code to test
use the most valuable tests only

A good unit test:

has a high chance of catching a regression error
has a low chance of producing a false positive
provides fast feedback
has low maintenance cost

Testing trivial code is not worth the cost.

Decouple tests from implementation details as much as possible.

Spend most of the time on testing business logic.

Styles of Unit Testing

output-based verification (functional style)
state verification
collaboration verification (uses test doubles)

Hexagonal Architecture

image from Wikipedia

Implementation Detail

Public API is the surface area that you can access from outside a class.

What are the requirements?

address an immediate goal of the client code
address that goal completely

Look at the client code: if it uses more than 1 operation to achieve a single goal, the class is leaking implementation details.

Note: Neighboring classes might be aware of implementation details.

Example: the Root Entity of an Aggregate (Domain Driven Design) might know about implementation details of the Entities.

Communication inside a hexagon is implementation detail.

Between hexagons a public API of the hexagon exist (contract).

Styles

functional style: has no state, easy to maintain, offers the best protection against false positive
state verification: should verify through public API, reasonable maintenance cost
collaboration verification: within the hexagon lots of false positives; between hexagons more stable

Black-Box Testing Vs. White-Box Testing

black-box testing: testing without knowing the internal structure
white-box testing: testing the internal structure

Adhere to black-box testing as much as possible.

Business Requirements

Does the test verify a business requirement?

view your code from the end user's perspective
verify its observable behavior

Integration Tests

test data cleanup: wipe out all data before test execution

Unit Testing Anti-Patterns

private methods: if needed expose the hidden abstraction by extracting a new concept
expose state getters: test the observable behavior only
leaking domain knowledge to tests: use property-paced testing, or verify end result
code pollution (introduce additional code just to enable unit testing)
overriding methods in classes-dependencies: violates single-repository-principle, instead split functionality into different pieces
non-determinism in tests: try to avoid testing async code (separate code into async/sync), use Tasks

Write Better in Neovim With Languagetool

Sophia Brandt — Wed, 26 Oct 2022 12:00:00 +0000

LanguageTool is a grammar tool and spell checker with an open-source core.

I have used grammarly for a while, but the browser extension was crap.

A colleague recommended LanguageTool (LT), and I’ve been a happy user of the browser extension ever since.

LT has superior support for other languages than English. It also features decent suggestions for improving your grammar. The free tier of LT has been a better experience for me than grammarly.

Did you know that you can use LT as a language server for NeoVim and other editors?

Install ltex-ls

LT has no direct support for the language server protocol, but fear not – a clever programmer has included the LT server in his LSP implementation.

The tool is called ltex-ls, and it’s free software.

You can find the installation instructions on the ltex-ls website.

For macOS, you can use homebrew:



brew install ltex-ls

The command installs the server as ltex-ls in your standard homebrew location and thus adds it to your $PATH.

If you manually install the program, make sure to add the binary to your $PATH, for example with fish_add_path.

Integration With nvim-lsp

Check the recommended configuration on the nvim-lsp GitHub and add the following configuration:



require('lspconfig')['ltex']({
 on_attach = on_attach,
 cmd = { "ltex-ls" },
 filetypes = { "markdown", "text" },
 flags = { debounce_text_changes = 300 },
})

You should add the server command into the cmd section. On macOS, ltex-ls worked fine for me.

Here you can see how the tool points out possible errors in my text:

Other Editors

I originally found the instructions for using ltex-lsp on a blog about the Helix Editor: Note talking with Helix, Tp-Note and LanguageTool.

Here is the the content of ~/.config/helix/languages.toml:



[[language]]
file-types = ["md", "txt"]
indent = { tab-width = 2, unit = " " }
injection-regex = "md|markdown"
language-server = { command = "ltex-ls" }
name = "markdown"
roots = [".git"]
scope = "source.md"

If you use VS Code, you can use the extension vscode-ltex.

Helix Editor – 90% of Neovim With Kakoune

Sophia Brandt — Wed, 26 Oct 2022 11:10:00 +0000

I’ve spend too many hours setting up the recent NeoVim features (since v0.5): tree-sitter, nvim-lsp, nvim-cmp.

Why?

NeoVim’s parser tool tree-sitter offers a better integration of language servers, syntax highlighting and auto-completion.

The Problem

Vim and NeoVim are great.

However, I put a lot of effort into customizing these editors to my liking, so that I could comfortably use them for coding.

In fact, my configuration has become more complicated over the years.

Migrating my Vim configuration to take advantage of tree-sitter was an exercise in frustration.

Better Than (Neo)Vim?

By chance I stumbled upon a review of Rust text editors on lobste.rs.

The article favorably mentions Helix, a modal text editor inspired by Vim and Kakoune.

Other commentators also seemed taken with this new text editor.

I gave Helix a try and I am pleasantly surprised.

Helix is a fully-fledged text editor that comes with wonderful capabilities out of the box.

For example, you get a fuzzy file finder, language server integration, a vim-surround-like plugin and great editor themes for free.

In the end, Helix offers almost everything I need from a terminal-based text editor with zero config.

After wasting hours of my free time on tweaking NeoVim, Helix’s sane defaults and inbuilt features blew me out of the water.

Kakoune – Why!?

Helix has one advantage over Vim/NeoVim - multiple cursors. This features makes text editing a smoother experience.

Multiple cursors come from Kakoune, a text editor I never heard of.

Vim’s core editing model revolves around verbs and (text) objects. For example, to delete a word, you type dw, like in a natural language like English.

Kakoune turns this model on its head: in Kakoune, you always select text objects first, then operate on them with words.

Helix uses the same model as Kakoune.

The idea is that you always start by making a selection first (that way it’s interactive and you see that you selected the right thing), then you operate on it.

I’m not sure if I can forego my muscle memory and retrain myself to use the “Kakoune” way. For me, it feels incredibly awkward.

I am also missing some commands in normal mode.

For example, I can easily move or copy lines to other locations in the file without having to make a selection and without leaving normal mode.

This is a clash with Kakoune’s/Helix’s philosophy.

What I am missing most is ci (for change inside).

I often use this command to change text in brackets (ci{), single quotes (ci') or other text objects.

Now What?

Helix is in active development.

But even so, the editor is already usable. Because it is written in Rust, it’s fast and stable.

The maintainers plan a plugin system with WebAssembly, which would be a big milestone for the project.

All in all, Helix looks like a valid alternative to Vim/NeoVim if you like modal editors.

My Configuration

Here is my complete configuration file:

theme = "nord"

[editor.cursor-shape]
insert = "bar"
normal = "block"
select = "underline"

[editor.statusline]
left = ["mode", "diagnostics"]
center = ["file-name"]
right = ["selections", "file-type", "file-encoding", "position-percentage", "position"]

[keys.normal]
g = { a = "code_action", o = "goto_last_accessed_file" }
"ret" = ["move_line_down", "goto_first_nonwhitespace"] # Maps the enter key to move to start of next line
X = "extend_line_above"
D = "delete_char_backward"

[keys.insert]
C-space = "completion"
# Move cursor in insert mode
A-h = "move_char_left"
A-j = "move_line_down"
A-k = "move_line_up"
A-l = "move_char_right"
A-o = "open_below"
A-O = "open_above"

It adds a default theme, a few convenience key mappings plus some customisation around the status-line and the cursor.

In comparison, here is my code for the status-line in Vim/NeoVim alone – which is (more or less) a three-liner in Helix.

My First T3 App

Sophia Brandt — Tue, 25 Oct 2022 20:00:00 +0000

tRPC is the hottest new thing in the TypeScript ecosystem: build end-to-end type-safe APIs without the overhead of GraphQL.

tRPC is a protocol to expose a function of your backend to your frontend using TypeScript type definitions.

No code generation required. You write both your backend and your frontend with TypeScript and share the types.

tRPC is framework-agnostic.

Create-t3-app is build on top of tRPC. It offers an opinionated starter template that helps with building a complete web application with Next.js and Prisma.

This blog post chronicles my journey in creating my first T3 app. Let's see how the T3 stack works!

Create Application

pnpm dlx create-t3-app@latest

The command guides you through the installation process and allows you to choose a few options (trpc, prisma, next-auth, tailwind).

I am happy to see that the command also works with pnpm out of the box.

The command bootstraps the application. At the end of the process, there is a hint on what commands to run:

cd my-t3-app
pnpm install
pnpm prisma db push
pnpm dev

The project also offers a README file with minimal information to get you started.

Prisma

My application should show cat pictures because the internet loves cats.

Let's adjust the Prisma schema:

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

+model Cat {
+  id        String   @id @default(cuid())
+  createdAt DateTime @default(now())
+  updatedAt DateTime @updatedAt
+  imageUrl  String
+}

This looks like a minimal example for a first application. Run pnpm exec prisma migrate dev --name add_cat_model.

tRPC Router

My next instinct is to hook up the trpc router. The project comes with an example router in src/server/router/example.ts. I'll adjust that to be a cat router.

The router uses zod, a schema-validation library, to build a router.

The example query has an input parameter of the String type.

For my case, I want a random cat picture, so no input is needed. Can I just delete the input parameter and return a random cat?

Before:

import { createRouter } from './context'
import { z } from 'zod'

export const exampleRouter = createRouter()
  .query('hello', {
    input: z
      .object({
        text: z.string().nullish(),
      })
      .nullish(),
    resolve({ input }) {
      return {
        greeting: `Hello ${input?.text ?? 'world'}`,
      }
    },
  })
  .query('getAll', {
    async resolve({ ctx }) {
      return await ctx.prisma.example.findMany()
    },
  })

After:

import { createRouter } from './context'
import { Cat } from '@prisma/client'

export const catRouter = createRouter()
  .query('random', {
    async resolve({ ctx }) {
      const randomCats = await ctx.prisma.$queryRaw<Cat[]>`SELECT id, imageUrl
                                                           FROM Cat
                                                           ORDER BY RANDOM()
                                                           LIMIT 1`
      return randomCats[0]
    },
  })
  .query('getAll', {
    async resolve({ ctx }) {
      return await ctx.prisma.cat.findMany()
    },
  })

I use a raw SQL query to retrieve a random cat from the database and add a typing for Cat[].

That's not pretty and does not give me the advantage of using the schema validator, but Prisma doesn't implement getting a random record. So raw SQL it is!

The raw query returns an array in any case, so we select the first element and return it.

Seed Script

Before I try to hook up the frontend, I remember that I don't have any example data in my database.

Luckily, the Prisma documentation can help me.

Add a new entry to package.json:

{
  "prisma": {
    "seed": "ts-node --compiler-options {\"module\":\"CommonJS\"} prisma/seed.ts"
  }
}

Create a new seed script in the prisma folder (prisma/seed.ts):

import { PrismaClient } from '@prisma/client'
import { fetch } from 'next/dist/compiled/@edge-runtime/primitives/fetch'

const prisma = new PrismaClient()

async function main() {
  const requests = Array(10)
    .fill('https://aws.random.cat/meow')
    .map((url) => fetch(url))

  Promise.all(requests)
    // map array of responses into an array of response.json() to read their content
    .then((responses) => Promise.all(responses.map((r) => r.json())))
    // insert all responses as imageUrl
    .then((cats) =>
      cats.forEach(
        async (cat) => await prisma.cat.create({ data: { imageUrl: cat.file } })
      )
    )
}

main()
  .then(async () => {
    await prisma.$disconnect()
  })
  .catch(async (e) => {
    console.error(e)
    await prisma.$disconnect()
    process.exit(1)
  })

I fetch ten image URLs from an API that offers random cat images and insert them into the database. Quite ugly, but it works.

In my terminal, I run type the following command:

pnpm exec prisma db seed

Success!

Hook Up the Client

Finally, we can try to show this data on the browser.

After ripping out the example router and replacing it with my cat router, I check src/pages/index.tsx.

It has some boilerplate which I adjust to my needs:

import type { NextPage } from 'next'
import Head from 'next/head'
import Image from 'next/image'
import { trpc } from '../utils/trpc'

const Home: NextPage = () => {
  const { data: cat } = trpc.useQuery(['cat.random'])

  return (
    <div style={{ display: 'grid', placeItems: 'center' }}>
      <Head>
        <title>T3 Cats</title>
        <meta name="T3 cats" content="Generated by create-t3-app" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <div>
        <h1 style={{ textAlign: 'center' }}>
          Create <span>T3</span> App
        </h1>

        <section>
          <div>
            {cat ? (
              <Image
                src={cat.imageUrl}
                alt={`random cat ${cat.id}`}
                layout={'fixed'}
                width={300}
                height={300}
              />
            ) : (
              <p>Loading...</p>
            )}
          </div>
        </section>
      </div>
    </div>
  )
}

export default Home

That was surprisingly easy, especially if you are familiar with Prisma.

First Impressions

The starter template does a good job on guiding you through the process.

The examples are enough to paint a broad picture on how trpc with Next.js works. Familiarity with prisma is assumed.

You might need to consult the Prisma documentation, trpc is almost self-declaratory, Prisma is not.

Setting Up a Modern Preact Application With Typescript, Vite and Vitest

Sophia Brandt — Sun, 16 Oct 2022 12:50:00 +0000

Wiring up a TypeScript environment with Preact, Vite and Vitest and vitest-dom

I have heard good things about Vite and Vitest. When I gave them a test-drive, I stumbled over some minor annoyances in getting the whole suite running.

I'm writing down the steps I took, maybe they help you.

The article is basically a re-write of a blog post by Tomoki Miyaci adjusted to my needs.

Tooling:

TypeScript
Vite
Vitest (with vitest-dom)
Preact
Prettier
ESLint
husky & lint-staged
commitlint

All my commands use pnpm, feel free to replace them with npm or yarn.

Vite

pnpm create vite <project-name> --template preact-ts
cd <project-name>
pnpm install

ESLint & prettier

pnpm i -D eslint eslint-config-prettier \
          prettier \
          @typescript-eslint/parser

Create a new file called .eslintrc with the following content:

{
  "env": {
    "browser": true,
    "es2021": true
  },
  "extends": ["eslint:recommended", "preact", "prettier"],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaFeatures": {
      "jsx": true
    },
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "settings": {
    "jest": {
      "version": 27
    }
  },
  "ignorePatterns": ["*.d.ts"],
  "rules": {}
}

One wrinkle was the Jest settings option. I know I wanted to use Vite, but eslint needs to know the Jest version for some of its tests.

Here is my Prettier configuration (.prettierrc), adjust to your needs:

{
  "trailingComma": "es5",
  "semi": false,
  "singleQuote": true
}

Let's adjust package.json:

{
  "scripts": {
    "lint:fix": "eslint --fix --ext .ts,tsx --ignore-path .gitignore .",
    "prettier:write": "prettier -u -w --ignore-path .gitignore \"*.{ts,tsx,css,html}\"",
}

husky & lint-staged

Install lint-staged.

pnpm add -D lint-staged

Create a .lintstagedrc.json file in your project root folder.

Here you can add the commands that lint-staged should run on staging your files.

{
    "*.{ts,tsx}": ["pnpm run lint:fix", "pnpm run prettier:write"],
    "*.{html,css,js,json,md}": "pnpm run prettier:write"
}

We run ESLint and prettier on TypeScript files in sequential order. For other files, prettier suffices.

Now we need husky.

We initialize it with a script:

pnpm dlx husky-init && pnpm install

The above command will setup the tool and create the necessary files and hooks.

The default hook runs before committing the files to the staging area.

You can find it under .husky/pre-commit:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

pnpm exec lint-staged
## if you want to run your tests before commiting,
## uncomment next line
# pnpm exec vitest run

commitlint

commitlint checks if your commit messages meet the conventional commit format.

Example:

chore: run tests on travis ci

I personally find it quite useful to enforce a uniform commit style.

commitlint pairs well with husky.

pnpm add -D @commitlint/{config-conventional,cli}

Let's add a configuration file (.commitlintrc.json):

{
  "extends": ["@commitlint/config-conventional"]
}

Now we need a hook for husky. Run the following command in your terminal:

pnpm dlx husky add \
  .husky/commit-msg 'pnpm exec commitlint --edit'

Vitest

Installation:

pnpm add -D vitest vitest-dom happy-dom

vitest-dom extends the standard Jest matchers with convenient methods like .toBeDisabled.

Now you can write tests that assert on the state of the DOM.

The package is a fork of @testing-library/jest-dom.

Configuring vitest with the .vite.config.ts:

/// <reference types="vitest" />
import { fileURLToPath } from 'url'
import { defineConfig } from 'vite'
import preact from '@preact/preset-vite'

// https://vitejs.dev/config/
export default defineConfig({
  define: {
    'import.meta.vitest': 'undefined',
  },
  plugins: [preact()],
  test: {
    environment: 'happy-dom',
    setupFiles: ['./__test__/test-setup.ts'],
    includeSource: ['src/**/*.{ts,tsx}'],
    coverage: {
      reporter: ['text-summary', 'text'],
    },
    mockReset: true,
    restoreMocks: true,
  },
})

The code section import.meta.vitest allows you to run tests within your source code.

For my test setup I've made a separate __test__ folder with a file called test-setup.ts:

import 'vitest-dom/extend-expect'
import * as domMatchers from 'vitest-dom/matchers'
import { expect } from 'vitest'

expect.extend(domMatchers)

Here I add the vitest-dom extra matchers. You can add more setup logic if needed.

Sources

Notes on ”The Counterintuitive Secret to Shipping Better Articles Faster”

Sophia Brandt — Tue, 22 Jun 2021 00:00:00 +0000

In this ~1 hour video developer advocate Sam Julien shares his tips for shipping faster:

tl;dr

You’ll need a system that enables you to consistently produce results on which you can get feedback on.

Action + Speed + Feedback = Growth

How to Create Consistently?

The problem:

The “Ultimate Guide” Trap : Trying to write a big, all-encompassing article leads to exhaustion and burn-out. You stop writing for months.

The Developer Content Creator Cycle

Overwhelming to know what to create
Difficult to cross things off the list (unfinished drafts)
Never-ending cycle

Explorer’s Mindset

Don’t think of content (or any other skill you’re building) as a dictionary to memorize.

Instead: think like an explorer.

The secret lies in Consistent Small Wins.

Comfort is the enemy of growth.

(But self-care, too!)

Sam does not encourage the “hustle mindset”.

How to Grow

Do challenging things quickly and get feedback.

What?

production-focused (article, video)
trackable
measurable

Getting feedback:

does it work?
learning in groups
learning in public

Building a Content System

Systems trump Motivation

Build a small but complete system.

1. Draft

gathering notes
creating an outline
first draft

2. Create

writing/recording
adding images
code samples

3. Publish

publish on your site
adding social images
cross-posting

4. Promote

Twitter threads
forums & chat groups
talks

5. Garden

Update over time
maintain & correct
cross-link

Creation Phase (Step 1 to 3)

Tools

Scratch pad

Eliminate the distraction of figuring out where to jot something down.

Look for: speed, ease of use, ability to export.

Google Keep, Drafts app, etc.

Knowledge Base

Slow burn your drafts and link your ideas together.

Look for: cross-linking, collections, multimedia.

Evernote, Obsidian, Roam, Notion.so, etc.

Task Manager

Ship things faster by determining the next action and context for a project.

Look for: works with your brain, ability to add context/tags

OmniFocus, Google Keep, etc.

Tips for Creating Content

In the beginning, move fast to define your process (do tiny expirements).
Start with what you know.
Stuck? Try the TIL format.
Don’t over-engineer too quickly.

TIL Format

Intro: 2 or 3 sentences describing the problem.
Body: describe the solution and how you got there.
Final Solution: Finished code for copy&paste.
Conclusion: 1 or 2 sentences re-capping the problem and solution.

Post-Publication Phase (Step 3 to 5)

Every piece of content has a price tag (promotion & maintenance).
Provide direct value on each platform (don’t dump your stuff).
Be patient.

Links

image credit for the cover image: Andy Li

Notes on “How to Write Online Workshop” by David Perell

Sophia Brandt — Mon, 21 Jun 2021 00:00:00 +0000

In this ~1 hour video David Perell explains his method for writing.

The Capture Habit

You need a note-taking system for generating better ideas.

What ideas should you save?

PILE :

personal
inspiring
easily lost (losable)
effective (useful)

Sources: ebooks, online articles – use a service like readwise.

Capture your ideas while you read.

Capture things while they are fresh.

Writing

Modern writing isn’t created. It’s assembled.

You have to cull your writing from vast amounts of notes.

Writing can be a collaborate progress. Ask for feedback.

The Content Triangle

image from Bronson Chang's notes

conversations -> share -> feedback -> create content -> distribute

2-minute-drill : explain your idea in 2 minutes or less by talking. Humans are better at talking than reading. After that, you can distill the audio to write your article.

You don’t need to be 100% original.

Improve Your Writing

CLEAR sentences:

Create a rhythm
Link your sentences
Eliminate anything that’s confusing
Add colorful details
Remove unnecessary words

Don’t just write words. Write music.

Sweet spot: words people know, but don’t say.

image from Bronson Chang's notes

Telling a Story

Roller-Coaster : start with a setup (tension rises), conflict, resolution.

image from Bronson Chang's notes

Learn to Write FAST

FAST Writing: write first, research second. Write in the course of your life.

Find
Assemble
Speak
Teach

Use your note-taking system, structure ideas by talking, record yourself, set a timer.

Audience

Grow your audience on public platforms. Build relationships on private ones.

Create value on public platforms.
Send audience to private platforms.
store value with your email list.

Build a Personal Monopoly

Define your personal monopoly:

specific (the more narrow the niche, the better)
unusual (skills or knowledge not often found together)
complementary (skills that reinforce and amplify each other)
experimental (skills gained through experience).

Aim for niche fame.

Get going. Then get good.

Writing and Thinking

When writing is thinking, re-writing is re-thinking.

When you put words on paper, you free up you mind which allows you to see things that you didn’t realize before.

When you write, you give yourself opportunity to go over ideas over and over again.

Imposter Syndrome

You are an imposter, because you are trying to do things out of your comfort zone.

But everyone is an imposter. David Perell didn’t know how to run a writing school before he tried. Jeff Bezos didn’t know how to run a trillion-dollar business like Amazon.

When you realize that everybody is an imposter, you realize that nobody is an imposter.

You have an obligation to share your ideas. This is how our society advances.

Notes on ”How to Build a Career in Tech”

Sophia Brandt — Sat, 19 Jun 2021 00:00:00 +0000

Kurt Kemple is a self-taught programmer who learned to code when incarcerated. In his talk with Jason Lengstorf he shares his experiences.

Here are my notes from the ~1 hour video:

Technical skills are a small part of your day to day job. Kurt learned how to prioritize, commmunicate with others and how to organize the work from his previous experience in construction work and as a line cook. Break a big task into small pieces.

Empathy and understanding : “Your perspective of the world is not the center of everything, it’s not the default. Lots of people have experiences that are different from yours.”

Know the stakeholders. Understand what they are invested in.

How to learn? Kurt learns best by doing. He breaks new skills into manageable chunks, and practices them step by step.

How to break into tech : Until you have your first role, you need something for your resume — either certificates or a great portfolio. You also want to highlight the skills you want to get hired for.

One of the best ways to break into tech is to build a community. Learn in public.

Often, job opportunities come from your network.

Resume tips:

two column layout (1 page): on the top left the most important info, below that the most important experience (certificate, a project), on the right side put the second most important info
make different resumes for different jobs

Remote work : traditionally, the advice for junior developers was to aim for an on-site job, but that’s not possible due to the pandemic.

Ideally, your future company either has a track record for remote work or already on-boarded junior developers.

Find the people in your job that are happy to answer your questions, and ask them — a lot. Communicate early, communicate often. Optimize for feedback.

Focus on the whys, not hows. Everyone can pick up the newest and hottest tech stack and learn how to use it. Rather aim to understand why to use a technology.

Jason Lengstorf, the interviewer, also explains that he doesn’t expect juniors to know a lot, but he wants to get the sense that the junior can find out (“self-starter”). Be confident in yourself, be confident in your ability to learn and grow.

Be aware of burnout. Don’t start a new job and deliver 110%. This becomes your baseline, and soon you’ll be expected to clock in 130%.

If possible, dedicate 70-80% to productivity on the job, and around 20-30% to learning and growing.

How do you learn to program when you don’t know enough about computers?

Try to get a basic understanding of how computers and the internet work, how to use the keyboard effectively. If you don’t know anything about computers, you’re trying to learn two things at once.

Notes on ”Advice for Your First Dev Role”

Sophia Brandt — Mon, 14 Jun 2021 00:00:00 +0000

Virtual Coffee is a remote community for developers that aim to support each other.

They offer "brown bags" which are talks and discussions about a specific topic.

Here are my notes from Advice for your first dev role by Bryan Healey:

Remember that there will be a ramp-up period. You should take the time to talk to other engineers in your team.

Learn about the tooling stack as soon as possible.

Talk to your manager regularly.

Keep in mind what you want to achieve in a year, 5 years, etc. Be proactive. Don't wait for tasks to come to you — gradually ask for more complex tasks. Take ownership.

Many juniors try to jump in and contribute at scale. That hinders them from seeking help, and opening a dialog. Having a "set of fresh eyes" is valuable for a company.

Bryan looks for continuous contributions on an escalating scale. He doesn't expect a junior to contribute major features right away.

Good engineers should be comfortable with asking questions as its part of the process.

A functional team will collaborate and discuss, so your questions should be welcomed, too.

When should you ask questions? As a beginner, don't spend too much time on trouble-shooting. Nobody gains much when you try to solve a problem yourself that could be solved faster by asking for help.

Rule of thumb: don't spend more than 30 minutes banging your head against the wall.

When you start a new job, there is a "grace period" where everyone expects you to ask questions. Build trust by doing your due diligence (take notes, learn, listen for feedback, etc.).

Also remember that seniors developers can learn from you.

Bryan hires junior developers for their personality, creativity, problem-solving, not for their technical skills. He looks for people that can push the team. He doesn't care about failure, not delivering things.

Don't be quiet, be part of the team.

Links

image credit: Marvin Meyer

Notes on “How to Become a Better Developer With Nacho Iacovino“

Sophia Brandt — Sun, 13 Jun 2021 00:00:00 +0000

Notes from the Twitch stream with Francesco Ciulla and Nacho Iacovino (1 hour 17 mins):

Nacho Iacovino is a self-taught developer from Spain who grew his Twitter account in a short time.

Here are some tips that he shared.

Coding interviews: He learned from each interview. Even if you can't answer a question, you can go home, research, and then you can answer the question on the next interview. It's a process.

You also need to interview the company.

Marketing/Followers: Nacho made some useful Twitter threads and pinged the influential Twitter accounts for feedback (no spam, no selling, add value), hit a niche (Tailwind CSS).

Engage with bigger account. Add value to other people's tweets. Use common sense.

Choose one platform and be consistent.

Becoming a better developer: He quit JavaScript twice before he managed to become a developer full-time. Be consistent. You might not have 6 hours a day to learn to code, but at least do a little bit every day.

Find the best way that works for you (video, tutorials, books).

Don't copy a tutorial verbatim, try to experiment, embrace breaking the application and find out how to fix it. Challenge yourself.

Portfolio: Show what you're capable of. Udemy project clones are dimes and dozens, make it your own. Make it easy for others to contact you.

Show the newest work first. Be concise. Say where you're based, so it's easy to see if the company can hire you.

Learn in Public: Nacho shared what he learned publicly on Twitter. People were reaching out to him, because they knew what he learned.

Be your own teacher. What you write down you can use later.