My inbox is FULL. Always. GitHub PR approvals. Google Cloud alerts screaming about latency. And—wedged right in between—execution reports from a few brokers politely informing me I did something… emotional.
For years I treated these worlds as unrelated. Coding was the rational, well-lit part of my brain. Trading was the fun, dopamine-fueled corner where rules were optional. That worked right up until a few “strong conviction” trades turned into a full-blown kernel panic in my P&L.
That’s when it clicked:
An options portfolio is just a distributed system with terrible documentation and hostile users.
If you wouldn’t run a production service on vibes, why are you running your money that way?
Years ago (when Java was ‘new’), I got a recommendation from a good friend to check out “Ah, Clean Code by Robert C. Martin”. He told me, “It’s not just a book; it’s a must-read to anyone who wishes to be a professional software developer.”
He was right. This is still one of the top five books that I recommend developers read. It focuses on some simple but important concepts that will make your Code better, simpler, and easier to debug.
More than aesthetics, clean Code is about clarity, maintainability, and efficiency. Investing in writing clean Code might seem time-consuming, but it pays off exponentially in debugging, collaboration, and scaling efforts.
Think of messy Code as a tangled web: complex to navigate and easy to get stuck in. Clean Code teaches you to weave a well-structured tapestry instead—clear, elegant, and easy to extend.
Here are 15 powerful lessons every developer should carry from this book, with practical examples:
Here is a set of commands I found using… There might be a lot of other useful commands.
Setting up a Git project
If you want to work with an existing project, clone it:
$ git clone <url> - for example: git clone https://greenido@github.com/greenido/html5-boilerplate.git
If you do not have an existing git project, create one:
$ cd project/
$ git init # initializes the repository
$ git add . # add those 'unknown' files
$ git commit # commit all changes, edit changelog entry
$ git rm --cached <file>... # ridiculously complicated command to undo, in case you forgot .gitignore
Git will look for a file named .gitignore in the root of your repository which contains a set of shell patterns to ignore in file paths.
Branching and merging
$ git checkout -b linux-work # create a new branch named "linux-work"
$ <make changes>
$ git commit -a
$ git checkout master # go back to master branch
$ git merge linux-work # merge changesets from linux-work (Git >= 1.5)
$ git pull . linux-work # merge changesets from linux-work (all Git versions)
Importing patches
$ git apply < ../p/foo.patch
$ git commit -a
Exporting a patch
$ <make changes>
$ git commit -a -m "commit message"
$ git format-patch HEAD^ # creates 0001-commit-message.txt
# (HEAD^ means every patch since one revision before the
# tip of the branch, also known as HEAD)
Network support
# clone from the primary Git repo
$ git clone git@github.com:greenido/html5-boilerplate.git
$ cd git
# pushing changes to a remote repo with SSH
$ git push user@github.com:my-repository.git/
# fetch changes to a remote branch into a local branch
$ git fetch user@example.com:my-repository.git/ remote-branch:local-branch
# merge changes from a remote machine
bar$ git pull git://foo/repo.git/ branch
# Serve repository via git protocol
$ cd /my/repository/
$ touch .git/git-daemon-export-ok
$ git daemon # now others can fetch from git://your.machine/my/repository/.git/
# Set up a bare (= without working directory) repository (e.g. on a webserver)
$ mkdir my-repo.git
$ cd my-repo.git
$ git --bare init
$ chmod a+x hooks/post-update # this is needed for HTTP transport
# you need to populate this repository via push
Inspecting revisions
# inspect history visually
$ gitk # this opens a Tk window, and shows you how the revisions are connected
# inspect history
$ git log # this pipes a log of the current branch into your PAGER
$ git log -p # ditto, but append a patch after each commit message
# inspect a specific commit
$ git show HEAD # show commit info, diffstat and patch
# of the tip of the current branch
Referring to revisions
# by name
$ git log v1.0.0 # show history leading up to tag "v1.0.0"
$ git log master # show history of branch "master"
# relative to a name
$ git show master^ # show parent to last revision of master
$ git show master~2 # show grand parent to tip of master
$ git show master~3 # show great grand parent to tip of master (you get the idea)
# by output of "git describe"
$ git show v1.4.4-g730996f # you get this string by calling "git describe"
# by hash (internally, all objects are identified by a hash)
$ git show f665776185ad074b236c00751d666da7d1977dbe
$ git show f665776 # a unique prefix is sufficient
# tag a revision
$ git tag v1.0.0 # make current HEAD known as "v1.0.0"
$ git tag interesting v1.4.4-g730996f # tag a specific revision (not HEAD)
Comparing revisions
# diff between two branches
$ git diff origin..master # pipes a diff into PAGER
$ git diff origin..master > my.patch # pipes a diff into my.patch
# get diffstat of uncommitted work
$ git diff --stat HEAD
Ido Green 