Nice explainer of the `g-and-h` distribution with interactive slider applying the quantile function, helps build an intuition for the function and how it transforms distributions.
- I would learn some technology to a point where it does what I want
- I take what I learned to some new technology but find myself doing things from what I learned in other technologies
- this puts me in a strange loop where reality wasn't lining up with my expectations or I would do things that were more work than necessary because of learned habits
- the aha moment was when i started learning the theory of the thing I was working with
* it was key to getting out of this rut
* turns out this applies to any theory from abstractions all the way down to computational theory, type theory, automata theory, software analysis theory, hey if i ever get there maybe even software synthesis
in a nutshell i would summarize this aha moment as "you can keep doing the same old tricks and eat the cost or you can always dig deeper and see what costs can be avoided."
this might be a bit vague so to put another way perhaps I learned to zoom in before zooming out, and once I have done something, it never hurts to zoom in again and see what can be gleaned from the assertions I was making about the world at the time. in practice some things I have learned to ask myself are
- what is the shape of the input data (requirements, configuration, dependencies are also data) of the thing I'm working with and what is the shape I'm looking to produce as output of this software (could be any combination of side effects, screens, or just data)?
- on a larger feature or set of features i look for a domain language to be discovered or did I create a domain language and does it hold true?
- what are the fundamental assumptions I was making and could they be improved from first principles?
- what is the expected and unexpected behavior of what I am building today or what I built in the past and why? (learning opportunities)
- the takeaways are my assertions are only as good as my understanding and understanding requires detail, attention to detail is only as good as my checklist, and my checklist is only as good as the questions I'm asking, this helps create a habit loop where I can hopefully improve outcomes with each iteration based on deeper introspection
This is a disturbing trend by IBs flexing their legal might against their (former) software engineers. Before automated trading systems there were traders who carried their strategies around in their heads. On the surface it appears to be a game of scale because these strategies and systems are so costly if a trader walked off with a strategy it was one less bonus check they would have to pay. But if an engineer walks off with the design of a trading system and some strategies, then the firm might have to come up with some new strategies which is a costly affair indeed. Given the extreme nature of modern cybercrime laws to thwart terrorism and safeguard our economic infrastructure should they be used against ex-employees to safeguard intellectual property? Perhaps an interesting legal debate given the stakes.
In my opinion the most important skill is philosophy, I think someone once asked "To be X or !X?" Without philosophy we have nothing, no science or math. If greatness is doing the best we possibly can at everything we do then that's "great" for us personally but does it make other's lives great as well? It is one thing to be of the highest possible skill level, or in other words "great", at something like programming but what if your goal is to make everyone who touches your work from testers to line managers live's easier? Wouldn't you be perceived as "great" regardless of your skills as a programmer? Will Smith seems like such a great guy his energy just radiates from everything he says and does and his work ethic is also inspiring. But a performing artist's role is probably more altruistic than someone in a technical role where the altruistic outcomes are less obvious. Start with philosophy my friends.
Here's a link to that article on The Economist that states there are too many people doing too much of _everything_ and life is hard in general. Oh wait, that doesn't exist yet perhaps because that's reality. It sounds like he has spent so much time doing everything but what he _should_ be doing which is looking for something he actually _enjoys_ doing. Not that the article wasn't insightful or lucid or anything but this article struck me in he clearly enjoys complaining about his work life than doing it so there's a problem. I don't love my job but I enjoy doing it most of the time and I have great hobbies, a great partner in life and am happier and fitter than I have ever been. Perhaps he should try doing different things and see how that works out as when you are doing something you don't have any expectations. Why would you say "I love science, I just don't love doing it?". I love Formula One cars but don't know anything about driving them but I love riding motorcycles, and riding bikes. He needs to find the action verb that defines his work life and not impose any expectations from a noun he associates with "love."
Man these are some awesome comments. "Self proclaimed" Rockstars != craftsman. Those who earned the title. Guido vonRossum et. al. are having their five minutes, let them have it, they took the risks. You can't blame the recruiter though, if they are looking to bring cocky, blowhards to the interview table and wow the upper "hangers-on" with their talk game. I think recruiting, much like a good programming environment needs to take bad decisions out of the equation or minimize the collateral damage thereof. Oh well, such is the state of recruiting and such is the ever changing complexion of software development. Time to go back to the guild and apprenticeship system. Any nobles out there? :p
reply