Concepts

When evaluating companies, its utmostly important to learn about the engineering culture. Culture for a company is simular to scope for code – culture provides a context for getting work done. Companies advertise their culture, but note that each company has a different culture. There’s plenty of articles about culture, so I won’t bother covering that. Just remember they aren’t necessarily the same. Companies tend not to be explicit about making sure their process matches what you expect. Be suspicious for a company that can’t explain it’s culture because that just means they’re not activitely trying to cultivate one. And that means it’s implicitly defined by the leaders of the company. Even if they choose not to define it. ...

Trying to concisely describe concepts is an interesting exercise. The ideal goal is to build upon existing concepts, but as you add more concepts you run the risk of being inconsistent. So with at most two sentences, I present a list of common programming concepts. This goes without warning that lossy compression is inevitable. Data: Ones and zeros. Values: Meaningful data. Types / Encodings: Interpretations of values. State: A value that changes over time. Usually also considered a Value. Variables: Names for values over time. Collections: A value that’s a a group of values of same type. Structs: A value that’s a group of values with possibly differing types. Classes: Structs with functions that have itself as the first argument. Inheritance: A concise way to implement a class by referring to part of its implementation from one class. Multiple Inheritance: A class that inherits from multiple other classes. Extensions: Adding methods to a previously defined type. Mixins: Adding (Multiple) Inheritance to a previously defined type. Interface / Protocols: Inheritance of a class that has only functions that should be implemented by the class that inherits it. Traits: Interfaces that may have function implementations. Generics: Treating a type as a variable. Allows algorithms independent of specific types. Type Classes: Generic Interfaces. Monad: An interface defining the expected behavior for map. Functor: An interface defining the expected behavior for apply. Pointers: A value that indicates where to find another value. An home address is a pointer to a home. Big-O Notation: A method to estimate the number of main-memory operations Slice: A value that is a pointer and length into an existing collection Value Objects: An struct / class with equality and hashCode semantics. Object-Oriented Programming: The concept of classes talking to each other using value objects. Procedure: A sequence of operations to execute. Most programming languages mean procedure when they say function. Function: Vaguely defined / blurred by current norms. See Procedure. Pure Function: A procedure that returns the same output for the same inputs. Side Effects: Any observable state that occurs besides a return value. Functional Programming: The practice of using less state and more pure functions. Code: A value that is a series of operations AST (Abstract Syntax Tree): Hierarchy of typed code Program: A collection of code that a computer that can execute. Compiler: Program that take code and produce programs. Interpreter: A program that executes code without producing a program. Emulator: A program that mimics the behavior of hardware. Virtual Machine: A computer emulator where the hardware may not actually exist (eg - Java Virtual Machine). Static: Known at compile-time. Dynamic: Known at execution-time. Type Checker: A program that validates what types flowing through your code. Type Inference: A compiler or interpreter feature can that deduce types without always explicitly specifying it in code. Optimization: Writing code for the computer first, instead of humans. Performance: Turning memory operations for lower frequency, and higher throughput. Reference Counting: Counting number of owners of a piece of memory to know when to free it. Garbage Collection: An embedded program that frees another program’s memory that is no longer being used. Reflection: Code that can inspect and/or modify itself as it’s executing. Macros: An operation that can be translated to a sequence of operations before program execution. JIT (Just-In-Time) Compilation: A feature of interpreters or emulators that compiles code during its execution. The last concept pushes the limits of definitions this concise. Some interesting implications result from these definitions: ...

When someone talks about abstractions, they’re usually trying to make the software more flexible. But that’s usually one of two kinds of abstractions. Build an abstraction to hide an implementation Abstractions that hide implementations are more commonly touted as good designs. Ruby’s Faraday abstracts the specific HTTP library implementation. Rails’ ActiveRecord abstracts the SQL you need to write to interface with a relational database. The Data Mapper Pattern abstracts the persistent storage from your application. ...

What’s the best way to model a solution? In software, there’s several common ways of building solutions that solve specific problems. It’s worth trying to identify their characteristics and the tradeoffs they make. Architect the Software After the Current Problem The easiest is way to model software. There’s no need to take in consideration of future solutions the user made want. Sometimes this is what you need. If you’re writing a throw-away program, the fastest possible way to implement it is to codify for the exact problem you’re trying to solve. An example are most shell scripts. They tend to not be abstracted and usually automate a very specific task. ...

The more you learn, the more this skill seems to be necessary. When missing a bug or a refactor opportunity, I wonder how did I miss this? Sure, everyone wants to learn from their mistakes. But noticing the little details gives you the opportunity to adapt. Massive function definitions starts off looking like an common pattern for code that needs to be refactored. Those dozen one-letter variables names probably should be better named. Shadowing a variable is prone to introduce errors in the future. All those mental notes form from being able to observe it. ...

Let’s mentally build an API for an an e-commerce site. Let’s say we’re tasked with building the cart & checkout portion of the API. Building a RESTful API seems like the natural choice. At first, a Cart seems like any other model entity in the system. But what about an multi-page checkout step? Allow partial updating of the Cart model (sounds like a job for PATCH). We need to preserve as much information as possible on the server to allow the user to pick up where they left off. Each update needs to be validated against the current known state of the world. Store credit may not fully cover an order that has an upgraded shipping method specified later on. The final cart has to be “commited” where final validations need to be performed before commited. An finally, the committed cart requires taking to third party APIs all along the way (shipping, credit card processing, tax calculations) as well as at the commit point. REST doesn’t provide an easy way to model this. ...

Instead of sounding prescriptive, this article is much more descriptive. I’m describing my regular workflows: what is working; what isn’t working. I’m documenting this for completely selfish reasons since it’s useful to track progression (if any). It happens to be a great inflection point since a recent illness has thrown me off my routine in the past week. Like most people, there’s a need to regularly do: Respond to messages (twitter, facebook, texts) Respond to mail (physical, email) Attend events (birthdays, social gatherings, meetups) Capture ideas (they tend to come up in the most random places) Living (rent, bills, taxes, laundry, cleaning) All while (attempting) to achieve other goals: ...

People always ask about how did you learn this or work so quickly doing that? It’s a tough question to answer elegantly. And it’s a cop-out to vaguely say I spent my free time looking into that particular topic. It’s a socially-acceptable excuse. But no doubt that this requires time. The time spent learning comes from somewhere, since we all only have 24 hours in a day for this. In our field, there’s always time you must dedicate to learning to keep up to date. ...

There’s a process behind every result. If you say, “we have no process, there’s no meetings”, then that’s your process. Admitting to no process simply indicates that you don’t have it formalized. A poorly defined process hurts. Processes enable efficiency and consistency. They can also act like a communication protocol among team members, teams, and organizations. Process can improve your quality. Let’s think about how you deploy an application. What does that process look like? A poorly defined deployment process is inconsistent – something undesirable for a deployment. At minimum, a quick checklist works: ...

As an engineer, one of the most valuable skills you can have is to communicate effectively. This applies both to your follow engineers as well as non-engineers (PMs, designers, business). Obviously, this advice is generally applicable, but many engineers don’t craft their communication to the business well. Common problems are: Talking too much about technical implementation. Talking too little about technical implementation. Too much technical implementation drowns out the important details that businesses are concerned about. It drags on discussions and meetings unnecessarily. Imagine if a designer talked for hours about how they picked the correct border radius value and color for their buttons in a meeting. That’s a waste of time for business stakeholders and engineers in that meeting. Getting far into the weeds like that quickly wastes discussions or meetings1. ...