Overall

As the preface of the book says, ‘This book is an attempt to explain to the world at large what goes on in the world of computers.’ Hackers and Painters really tries to answer a lot of non-technical questions in a technical way.

Hackers are Makers

• Hackers are not cold and precise, they are messy. Hackers need taste.
• The ‘computer science’ terminology is mostly a hodge-podge.

Measurement and Leverage

• Measurement is needed for transforming work into impact
• Technology is leverage

The Hundred Year Language

• Modern languages are adopting more and more layers of in-directions
• Newer languages will be easier for human to reason about
• More of future CPU cycles are going to be used for building abstractions

God is in the details. - Architect Ludwig mies van der Rohe.

Overall

Martin is mostly known for Agile development, as he is one of the major contributor of the Agile manifesto. However ‘Clean Code’ is, in my opinion, his best work. Because he clearly explained that clean code means to craftsmanship and professionalism.

Code is People first

Many works have defined code as the ‘media of communication’ between IT systems and people. And it’s meant equally for people and machines, if not more for people. Because the only code that survives would be those utilized and understood by human. Extending that, for something to be understandable, it must be ‘clean’. One of my favorite quote in the book: “Clean code is more of a story to be told to people, than instructions for machines”.

Clean Code is Craftsmanship

Clean code is also crucial for professional survival, as the authors pointed out. Software systems constructed are living entities, and constantly evolve. The only possible way for a system to evolve is to keep the code ‘clean’, so both seasoned developers and novices can work on it.

Overall

Following lecture notes of Carnegie Mellon University’s class notes on ‘Principles of Programming’, I came to know about ML through this book. The book is intended to be a beginner’s tutorial, and ate the same time, a small handbook for implementation.

Being a mostly ‘academic’ language, standard ML has not been popular outside colleges. However, SML possesses a great benefit – convenience to teach about mathematically proof of program correctness. Most programs in ML comes in the form of induction-generated proofs.

ML also cleans up all loopholes of mutability and cleanly hides all form of lower-level machine operations. The result is a ‘pure’ functional language, bursting with atomicity (parallel safety) and very convenient strict typing.

Caveat

This book might not be useful in a practical job and generate impact in product. However it works for deepening the understanding of various computation concepts. In time, this makes one a better developer.

Motivation

Aiming at changing my perspectives about programming, I decided to start learning Lisp, the very first functional language. ‘The Little Schemer’, all references I’ve found highly suggested this as the starter book. And this is great for learning the functional way of thinking about computing.

What’s Good

Very delightful and light-weighted, in both the writing style and the length of the book. The entire book is organized as dialogues. With authors motivating active thinking in every single step, the very complicated ideas are unveiled. To my opinion this is the most effective way of learning, as it gives readers the illusion of inventing Lisp themselves. This work is also extremely short 200 pages, considering Lisp/Scheme is such a vast language. Authors managed to deliver the power fundamentals of s-expressions and lists.

The Five Rules

• The primitive car is defined only for non-empty lists.
• The primitive cdr is defined only for non- empty lists. The cdr of any non-empty list is always another list.
• The primitive cons takes two arguments. The second argument to cons must be a list. The result is a list.
• The primitive null? is defined only for lists.
• The primitive eq’l takes two arguments. Each must be a non-numeric atom.

Follow-up Thoughts

Though Lisp is currently very much a research language, and of little production use. The real value it provides is a way of thinking about computing. And the recursive nature of s-exp is the very best descriptor of recursive data structure and algorithms.

The beauty of Lisp is that it can be entirely derived from a tiny, compact core of a short list of axioms:

Craftsman mindset: Stop worrying about what your job offers you, and instead worry about what you’re offering the world.

The Passion Hypothesis

To simplify things, I’ll use the “passion hypothesis” to refer to the popular belief that the way to end up loving your career is to first figure out what you’re passionate about, and then pursue it (a strategy often summarized with the pithy phrase, “follow your passion.”) The more I studied this hypothesis, the more I noticed its danger. This idea convinces people that there’s a magic “right” job waiting for them, and that if they find it, they’ll immediately recognize that this is the work they were meant to do. The problem, of course, is when they fail to find this certainty, bad things follow, such as chronic job-hopping and crippling self-doubt.

But without the passion hypothesis to guide us, what should we do instead? How do people really end up loving what they do? To answer this question we need to turn our attention to an unexpected career adviser.

Becoming a Craftsman

In a 2007 episode of the Charlie Rose show, Rose was interviewing the actor and comedian Steve Martin about his memoir Born Standing Up. They talked about the realities of Martin’s rise. In the last five minutes of the interview, Rose asks Martin his advice for aspiring performers.

“Nobody ever takes note of [my advice], because it’s not the answer they wanted to hear,” Martin said. “What they want to hear is ‘Here’s how you get an agent, here’s how you write a script,’ . . . but I always say, ‘Be so good they can’t ignore you.’ “

In response to Rose’s trademark ambiguous grunt, Martin defended his advice: “If somebody’s thinking, ‘How can I be really good?’ people are going to come to you.”

If you’re not focusing on becoming so good they can’t ignore you, you’re going to be left behind. This clarity is refreshing. It tells you to stop worrying about what your job offers you, and instead worry about what you’re offering the world. This mindset–which I call the craftsman mindset-allows you to sidestep the anxious questions generated by the passion hypothesis—“Who am I?”, “What do I truly love?”—and instead put your head down and focus on becoming valuable.

Martin’s advice, however, offers more than just a strategy for avoiding job uncertainty. The more I studied it, the more convinced I became that it’s a powerful tactic for building a working life that you eventually grow to love. As I’ll explain below, regardless of how you feel about your job right now, adopting the craftsman mindset can be the foundation on which you build a compelling career.

Career Capital Theory

Research shows that the traits that lead people to love their work are general, and can be found in many different career paths. They include things like autonomy, a sense of impact and mastery, creativity, and respect and recognition for your abilities. Once you recognize that these traits have little to do with following a pre-existing passion, and can be cultivated in many different fields, you can safely abandon the myth that there’s a single right job waiting out there for you.

Of course, this still leaves open the question of how you gain these factors in your working life. One of the first things I noticed when I began to study this question is that these traits are rare. Most jobs, for example, don’t offer their employees great autonomy and the ability to make a big impact. If you’re a recent college graduate in an entry-level job, you’re much more likely to hear “go change the water cooler” than you are “go change the world.”

By definition, we also know that these traits are valuable—as they’re the key to making a job great. But now we’re moving into well-trod territory. Basic economic theory tells us that if you want something that’s both rare and valuable, you need something rare and valuable to offer in return—this is Supply and Demand 101.

When you hear the stories of people who ended up loving what they do, this same pattern comes up again and again. They start by painstakingly developing rare and valuable skills—which we can call career capital. They then leverage this capital to gain rare and valuable traits in their career. These traits lead to a feeling of passion about their working life. If career capital is the key to developing passion, then this explains the importance of Steve Martin’s craftsman mindset. By focusing on becoming so good they can’t ignore you, you’re maximizing the rate at which you acquire the capital you need to take control of your livelihood.

Passion 2.0

“Follow your passion” is an appealing idea because it’s simple and immediate. If you can figure out what you’re meant to do, it promises, a deep love for your career is just around the corner. The reality I’m proposing is less glamorous. It argues that passion takes time and hard work—harder work than most people naturally invest in their jobs. It’s also less certain in the sense that you cannot predict in advance the details of the compelling career you’re cultivating. But it compensates with clarity.

Stop worrying about what the world owes you, it says, and instead, put your head down, like Steve Martin developing his act, and strive to become so good you can’t be ignored. It’s this straightforward goal—not some fairy tale about dropping everything to pursue a dream job—that will lead you toward a working life you love.

Original article: http://lifehacker.com/5947649/steve-martins-advice-for-building-a-career-you-love

Overall

Software Engineers spend a huge amount of their career on debugging existing code: production or developing, own code or vendor packages. Yet people don’t spend as much time reason about the methodology behind these time spent. David J. Agans set out to address this issue from his experiences of both hardware and software.

The Nine Indispensable Rules

• Understand the System
• Make It Fail
• Quit Thinking and Look
• Divide and Conquer
• Change One Thing at a Time
• Keep an Audit Trail
• Check the Plug
• Get a Fresh View
• If You Didn’t Fix It, It Ain’t Fixed

Since all projects are extremely diverse, the debugging rules need to be highly abstracted out. Even harder, debugging is such a unique kind of activity, that it is as much of a creation process as designing the product itself. In many ways, the author compares it to detective fictions.

Scientific method fails to capture such creativity, and the best we have got is a series of guidelines from various personal perspectives. The author did a great job to summarize a huge amount of experiences into 9 simple and powerful sentences.

Motivation

Happy July 4th! During the holiday I’ve decided to take another look at the new shiny Atom/Nuclide code editor. Although I’ve spend a couple of years on Sublime test, and a year or so on Emacs, exploring great tools it still great fun.

After poking around for three hours, it turns out to be a NO. And I would like to reason about it.

Modal editing is a blessing

As discussed in a previous post, the majority of the time spent in text editors is actually browsing around. Atom really shines at displaying code in a beautiful GUI, and it offers fuzzy search of file names that are on par with all of other editors. However when it comes to defining clear modal contexts, it falls short.

Vim/emacs are defined with clear context in mind, which allows maximum knowledge transfer after one learns about the basic of one context. If you are in a grep-mode, you can expect all the shortcuts (most important ones are ‘n’ and ‘p’) to work in that context. In Atom it’s a chaos of interfaces. Each plugin tries to define some unique UI that does not follow the convention of the others. And the shared context is nowhere defined.

Command line efficiency

I spend a great amount of my day working in terminal window, which is a great time-saver. For almost all known tools, command-line versions have less bugs and run much faster. The performance for Emacs to open a file is noticeably faster than atom. Same for syntax highlighting and automatic styling code.

For finding hidden features in the editor, all editors evolved into some search solution. On Atom this is achieved with command palette fuzzy search, on Emacs this is done via ido.el/helm.el. In a GUI setting Atom wins for much easier access to commands and descriptions for each selection.

After all, coding speed is limited in thoughts, not tools

For over 50 years, engineers are stuck on keyboards and they have yet to discover/input a better input device. If this does not change, the efficiency for human-code interaction is not likely to see a dramatic change simply from improving current tools.

In a nutshell, software is purely thought stuff. And for most engineers, the real bottleneck for productivity is actually the speed of organizing thoughts. It would certainly be easier with better tools. But as far as thoughts are organized into texts, mainstream editors are almost equal at efficiency.

Synopsis

Yet another classics on computer theory. Charles Petzold is famous for ‘Programming Windows’ series. In this one he set out to explain how code is central to transmitting and processing information. ‘Code’ is pun-intended here.

This is not a common textbook that explains how electrical digital computers work, even though the author achieved it. The book is organized from a scenarios-driven way; aims at deriving how computers evolve instead of showing the computer architecture as of today. How is code invented the way it currently is? How does computer came to know and use it? And how do human use code to communicate between each other and other information processor?

Code in Life

Beyond computers, code is generalized into abstract vehicles that carry information under contexts. The author has shown how civilization has derived more than natural language: drawings, Morse codes, Braille, binary codes, and lengthy modern software. At certain points in history, these inventions serve a purpose of recording, conveying and processing info between various entities. And to the latest and most theoretical, bits as the building blocks of currently comprehended information. Computers are no longer only about numbers and arithmetic, they are abstracted to a much higher level of autonomous entities in the worlds of bits.

Overall

Javascript being ‘the most misunderstood’ language, really deserves a good book. This is the closest people have got to be ‘the only’ book you need for Javascript. The author successfully explain the fundamentally difference of the language’s prototype-oriented nature. Therefore fundamentally changes the reader’s perspective on the structure and mentality of programming in it. Definitely a must-see.

Where it shines

The book does a good job of explaining all the components of the ECMA standardized version of javascript. Especially explains the often confusing variable scope: variables don’t have block scope, they are either global variables or inside a function scope. This is a result of the availability of direct references to global variables at any level of nested functions.

The author also spend great length to describe the prototype model of OOP. This is another attractive feature of Javascript that also makes it hard to grasp on. However when familiarized, this becomes so handy that the more commonly used class-driven OOP looks very verbose.

Overall

Though named a ‘manual’, it’s actually a very good textbook for the introduction of algorithms class.

In the first half of the book, the author gives a very good overview of all the types of algorithm questions for a student’s angle. And it clearly states the book’s focus–combinatorial problems. The most value in the book comes from the second half, where it lays out the different types of problems and useful resources. Particularly useful to a less experienced software engineer, all problems the book describe have book references and implementations available in link.

Definitely worth reading a second time, and keep it close by hand! More, a lot of exercises have solutions here: http://www.algorithm.cs.sunysb.edu/algowiki/index.php/Main_Page