There is no automation other than automatically running this shell script whenever a commit is pushed to whatever branches are active. You don’t need to think very hard to see how this will break down at a certain point. Continue reading →
Suppose you want to write a simple in-memory JSON store with an equally simple socket based protocol. You want this in-memory store to support parallel and consistent reads. By “parallel reads” what I mean is if 10 clients request to read data from the store then no client should be blocking any other client. By “consistent reads” what I mean is when a client requests some data from the store there is absolutely no way that client gets half of the data before a write and half of it after a write and there is also some kind of ordering for reads and writes. In other words, if we have an array “[1,2,3,4]” that corresponds to the key “ints” in our JSON store then the following sequence of events is impossible: Continue reading →
Coders gonna code. Designers gonna design. Project managers gonna manage. Architects gonna architect. Vice presidents gonna vice preside, etc. The point is that if you have 10 designer, or 10 coders, or 10 project managers then they are all gonna do what you are paying them to do. None of them will stop and think for a minute that there isn’t work for 10 designers, 10 coders, or 10 project managers.
When people say one programmer is more productive than another what they really mean is that the more productive programmer in general writes code with better structure. Part of that structure is following the conventions of the language and the community and so the code is easier to follow and reason about. But there is also another component of the structure that is harder to quantify and describe, Continue reading →
Do you ever wonder why almost every library out there is a convoluted mess of ill conceived abstractions with ill defined composition semantics? I do all the time and I think I have finally figured out why. Continue reading →
If you want to become a better programmer then stop thinking in code. Programming is ultimately about solving problems with a predetermined set of abstractions. How these abstractions are expressed syntactically is irrelevant. So you should be practicing how to glue abstractions together instead of chasing the latest idioms and design patterns and incorporating them into your latest framework. This is why lisp programmers, and functional programmers in general, are better programmers. Functional languages force you to practice thinking with abstractions instead of low-level details and so over time functional programmers become better problem solvers because every time they sit down to program they are practicing better mental habits.