Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.
This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would
| # Compiled source # | |
| ################### | |
| *.com | |
| *.class | |
| *.dll | |
| *.exe | |
| *.o | |
| *.so | |
| # Packages # |
When setting up git for the first time on your computer, you'll need to configure it before you can really use it. This guide below outlines some of the well-known and lesser-known configuration options that I've found to be super helpful in the past.
The commands below are essential to run when configuring your git installation.
| create or replace function isdate(s varchar) returns boolean as $$ | |
| begin | |
| perform s::date; | |
| return true; | |
| exception when others then | |
| return false; | |
| end; | |
| $$ language plpgsql; |
| for z in */*.zip; do unzip $z -d $(dirname "$z"); done | |
| for z in */1024watermarked; do mv $(dirname "$z")/1024watermarked/* $(dirname "$z")/; done | |
| for z in */*.jpg; do rename -a $(dirname "$z"); done |
Satoshi Nakamoto's development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or "intrinsic value" and no centralized issuer or controller. However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin. Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments ("colored coins"), the ownership of an underlying physic
I hereby claim:
To claim this, I am signing this object:
From a lecture by Professor John Ousterhout at Stanford.
Programmers tend to worry too much and too soon about performance. Many college-level Computer Science classes focus on fancy algorithms to improve performance, but in real life performance rarely matters. Most real-world programs run plenty fast enough on today's machines without any particular attention to performance. The real challenges are getting programs completed quickly, ensuring their quality, and managing the complexity of large applications. Thus the primary design criterion for software should be simplicity, not speed.
> Occasionally there will be parts of a program where performance matters, but you probably won't be able to predict where the performance issues will occur. If you try to optimize the performance of an application during the initial construction you will add complexity that will impact the timely delivery and quality o
