Tripta Gupta @triptagupta - Tumblr Blog

Check Yourself Before You Wreck Yourself

"For the past few months, I’ve been exploring software design patterns, both at their roots and in their modern implementations. I’ve been exploring new languages and deepening my understanding of the languages that I already use. Man can I ever tell ya, it’s been exhilarating.

I started reading a new book last night, given to me by a CS professor who has been extremely kind to me. It was written in 1979, published by IBM: “Structured programming, theory and practice“. In the preface to the book, the authors discuss the beginnings of the software development field (originally an afterthought to hardware, and an error-prone, cut-and-try process) and its evolution into a true discipline where a programmer could solve a problem correctly, the first time, with no mistakes. I found one statement incredibly profound, contrasting ad-hoc spray-and-pray methods with true precision: “A programmer can gain 10 years of experience, or a programmer can get the same years experiences 10 times over.” Wow. How true.

If there is any fundamental evil in the profession of software, it must be that horrible trial and error loop that is the result of a lack of understanding – about the problem at hand (if it has even been defined), the tools at your disposal, existing solutions, or all three. When we allow ourselves to subsist in such a state, we waste the little time we have on this planet. We become triflers and busy bodies, always scurrying about in a rush yet never accomplishing anything of significance.

Have you ever met someone who has been in the field for years, yet still seems to have abilities only slightly better than that of a novice? I have. In contrast, have you ever met a “whiz” who seems to make incredible progress in short amounts of time? I’ve met a few of those as well.

In Daniel Coyle’s “The Talent Code: Greatness isn’t Born, it’s Grown,” the process of building skill is discussed and examined at length. The book opens with a story about a girl who does a month’s worth of practice in five minutes, without even knowing it. This seems like a fantastic claim from the outset, but as the book progresses Coyle makes his case. Coyle claims that while duration of practice is indeed important, the method of practice is a far more effective mechanism for building talent. Coyle examines Russian Women’s Tennis Champions, South Korean Golf Champions, Brazilian Soccer Players, World Class Musicians and Singers, Surfers, Chess players, elite magnet schools and more. His argument is that in all cases – elite performers don’t simply spend lots of time in their respective courts – they spend their time doing completely different things. Elite performers focus on developing a fluency with the fundamentals. They “chunk” their learning such that each piece is mastered independently of the whole.

I feel software development is a field where this is especially true. From my own experiences, I know that my greatest personal gains have come from:

- Deep study of fundamentals. Language fundamentals. Programming paradigms. Data structures. Repetition of those fundamentals. - Application of those fundamentals in more holistic contexts. - Closely examining (not just reading, but PORING OVER) code written by more capable programmers

Conversely, I can say that my own gains plateau when I find myself debugging code I don’t understand, using tools I don’t understand, and staying in my comfort zone (ie writing code and designing systems I already know how to write and design). The longer I subsist in this state, the harder it is to get back to doing it right. Complacency and ignorance breed the same.

CS Lewis states in the preface to “The Great Divorce” that “when a man faces a fork in the road and chooses incorrectly, he will never reach his desired destination by continuing. He must backtrack to where the error was made and begin again on the correct path.”

A programmer will never grow in a state of willful ignorance and repetitive, mindless busy work. A commitment to knowledge and understanding, being guarded against error, a passion for our craft; These are the building blocks of growth. This is how we evolve…quickly."

Evolving by Calvin Froedge

"In the end, this is a really simple idea: when you have several different ways to do something, your first choice should be the way that signals what you are trying to accomplish in a natural and obvious way. That may mean borrowing an idiom from a language that expresses that idea more succintly or more directly.

And when you eschew the natural and obvious idiom, it should be to signal that you have a different intent, that your exception to the standard idiom reflects the code’s exceptional nature."

Poignant Advice from Rob Pike

"After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, "I know what's wrong." He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about *how* that problem could happen, he'd intuit where the model was wrong or where our code must not be satisfying the model.

Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs."

http://www.informit.com/articles/article.aspx?p=1941206

How long will you need to find your truest, most productive niche? This I cannot predict, for, sadly, access to a podium confers no gift of prophecy. But I can say that however long it takes, it will be time well spent. I am reminded of a friend from the early 1970s, Edward Witten. I liked Ed, but felt sorry for him, too, because, for all his potential, he lacked focus. He had been a history major in college, and a linguistics minor. On graduating, though, he concluded that, as rewarding as these fields had been, he was not really cut out to make a living at them. He decided that what he was really meant to do was study economics. And so, he applied to graduate school, and was accepted at the University of Wisconsin. And, after only a semester, he dropped out of the program. Not for him. So, history was out; linguistics, out; economics, out. What to do? This was a time of widespread political activism, and Ed became an aide to Senator George McGovern, then running for the presidency on an anti-war platform. He also wrote articles for political journals like the Nation and the New Republic. After some months, Ed realized that politics was not for him, because, in his words, it demanded qualities he did not have, foremost among them common sense. All right, then: history, linguistics, economics, politics, were all out as career choices. What to do? Ed suddenly realized that he was really suited to study mathematics. So he applied to graduate school, and was accepted at Princeton. I met him midway through his first year there--just after he had dropped out of the mathematics department. He realized, he said, that what he was really meant to do was study physics; he applied to the physics department, and was accepted. I was happy for him. But I lamented all the false starts he had made, and how his career opportunities appeared to be passing him by. Many years later, in 1987, I was reading the New York Times magazine and saw a full-page picture akin to a mug shot, of a thin man with a large head staring out of thick glasses. It was Ed Witten! I was stunned. What was he doing in the Times magazine? Well, he was being profiled as the Einstein of his age, a pioneer of a revolution in physics called "String Theory." Colleagues at Harvard and Princeton, who marvelled at his use of bizarre mathematics to solve physics problems, claimed that his ideas, popularly called a "theory of everything," might at last explain the origins and nature of the cosmos. Ed said modestly of his theories that it was really much easier to solve problems when you analyzed them in at least ten dimensions. Perhaps. Much clearer to me was an observation Ed made that appeared near the end of this article: every one of us has talent; the great challenge in life is finding an outlet to express it. I thought, he has truly earned the right to say that. And I realized that, for all my earlier concerns that he had squandered his time, in fact his entire career path--the ventures in history, linguistics, economics, politics, math, as well as physics--had been rewarding: a time of hard work, self-discovery, and new insight into his potential based on growing experience.

via Robert Weisbrot

"How I explained REST to my wife"

We learned about REST this week. The simplicity of Ryan Tomayko's explanation in How I explained REST to my wife made me smile. I don't know much about previously used distributed systems' architecture like SOAP or WSDL, but would probably appreciate an explanation of each in Tomayko's style.

A quick and accessible read. Kudos, Ryan!

A designer knows he has arrived at perfection not when there is no longer anything to add, but when there is no longer anything to take away.

Antoine de Saint-Exupery

David Cole & Principles of Product Design

David Cole, a Product Designer at Quora, spoke about product design principles (a principle is "a law or rule that has to be, or usually is to be followed, or can be desirably followed, or is an inevitable consequence of something"). Product is a vague word. Product, as David puts it, is part of the larger ecosystem of business. Businesses are not just halves of a market, sellers of goods, etc., but more so drivers of outcomes. When we have a sense of what these goals and outcomes are, then the question of "what kind of product do we want to build?" and "how do we build it?" need to be addressed. Process of creating massive change in technology would've been called invention decades ago, but now its called design.

Some highlights from the talk:

- Never compromise -- Understand why the things that you've created didn't work because of your beliefs and assumptions and theirs. Ask yourself what assumptions that you held which supported your decisions.

- Embrace being wrong -- Exist within an organization that is OK with being wrong.

- Build progressively -- Don't underestimate the need to understand the requirements of each piece of your creation.

- Identify a central metaphor -- "Find a central metaphor that's so good that everything aligns to it. Design meetings are no longer necessary, it designs itself. The metaphor should be crisp and fun." - Alan Kay

- Focus on problems -- Since very few products succeed in their first iteration, you don't want to find yourself stuck on a single solution. That is, a situation in which you become so keen on a single solution that you simply invest in maintaining your solution rather than scaling it.

I found the talk to be loaded with generalizations accompanied by mundane examples. Some visual examples would have been a nice touch.

David brought up a few topics that led me to tangents of my own. Some of my findings:

1) Paul Rand's Thoughts on Design -- http://www.paul-rand.com/foundation/thoughts/#articles

2) Slow Web Movement, by Jack Cheng -- http://blog.jackcheng.com/post/25160553986/the-slow-web

3) Design & Compromise, by Mills Baker -- http://metaismurder.com/post/11186748510/design-compromise

4) What is the role of a product designer at Quora?, answered by David Cole -- http://www.quora.com/Quora-Product-Design/What-is-the-role-of-a-product-designer-at-Quora

5) Who Owns the Website, and Why, by Daniell Morrill -- http://distributionhacks.com/who-owns-the-website-and-why

KISSmetrics & the Scientific Method

Hiten Shah, of KISSmetrics, gave a talk at DBC last week and there was one piece of advice he gave that really resonated with me. He told us to be as experimental as possible and approach our creations, whatever realm they may fall in, using the scientific method. Create models, use controls and variables, execute, and then repeat after the execution goes awry. For example, when you're talking to people about your product and you start hearing the same thing over and over again, you need to go back and reanalyze your approach. Change the question you're asking, who you're asking it to, etc. Reanalyze your model, i.e., figure out which control didn't work, modify it, implement it into your model and re-execute. Rinse and repeat. Most of this is obvious for me due to my past life, but it's always nice to have it reiterated to me in a new context.

#KISSmetrics

thoughtbot

The Rails community has been abuzz with object-oriented programming, SOLID principles, laws, design patterns, and other principles, practices, and patterns. We’ve (re)discovered new tools and techniques to separate and reuse logic, making code easier to test, understand, and maintain. Now that...

triptagupta

"Abstractions can grant you infinite flexibility but zero readability."

Study changes a man, puts pride into him. You need it to get to the bottom of life. Without it you just skim the surface. You think you're in the know, but trifles throw you off. You dream too much. You content yourself with words instead of going deeper. That's not what you wanted. Intentions, appearances, no more. A man of character can't content himself with that. Medicine, even if I wasn't very gifted, had brought me a good deal closer to people, to animals, everything. Now all I had to do was plunge straight into the heart of things. Death is chasing you, you've got to hurry, and while you're looking you've got to eat, and keep away from wars. That's a lot of things to do. It's no picnic.

- Louis-Ferdinand Celine, Journey to the End of the Night

Enumerable Cheat Sheet

Yet another, but I particularly like this one: http://www.davidegrayson.com/ruby/enumerable/enumerable_methods.pdf

"When programming in the Ruby language, it is essential to know about the Enumerable module. The more Enumerable methods you know, the more concise and elegant your code will be. The Enumerable module is mixed into many common classes such as Array, Hash, and Range. It is also mixed into some not-so-common classes such as Set and Enumerator."

via http://blog.davidegrayson.com/2012/03/ruby-enumerable-module.html

Joe Conway's Advice on Learning

Highlights from Joe Conway's Advice on Learning:

1) "I ask mentors how to solve problems, but only after I’ve tried every solution I can think of. Exhausting my knowledge before asking a question serves two purposes: I don’t waste their time with frivolous or ambiguous questions and I now know all of the wrong ways to solve the problem. Knowing all of the wrong ways to solve a problem is just as important as knowing the right way, by the way.

2) "Sometimes, people are hesitant to ask questions because they don’t want to be a bother. This actually leads into my next step of learning: taking on proteges. I find that simply trying to extend my understanding to someone else will reveal my misunderstandings and weaknesses. Both the mentor and protege have something to gain and the thus the world wins. It is important to maintain a dynamic list of mentors and proteges; simultaneously taking in knowledge and translating it to others."

3) "... I don’t accept everything I learn without challenging it. However, how I challenge it is important. Sometimes, a mentor will say something and I will think, “That can’t be right, because A, B and C.” Instead of arguing with my A, B and C arsenal, I try to find out if there is a D that I don’t know about. When there is a D, I have successfully avoided looking like a jerk and I have learned something new. When there isn’t a D, both the mentor and I have learned something.

4) "The final piece of learning is simply experimentation. I try some stuff. Sometimes it’s trivial, sometimes it is ambitious. I know that for every line of code I write in this new platform, I’m going to have to rewrite it three times; then I forget that fact because it is makes me want to go back to the warm embrace of Xcode. I share what I’ve done. I write about it. I read about it."

"What do you like most about programming... so far?"

My mentor Pamela Fox asked me this question during lunch yesterday. I spent the previous day happily working on an anagram problem so I quickly had an answer. I broke down the problem by first comparing whether two words are anagrams, then expanded it to take an array of strings, and then discussed with Jesse how to expand the code so I could use it for any large body of text. Walked away incredibly blissed out. The mental state that I entered allowed me to forget about where I was in comparison to the rest of the class. In fact, that state made me realize that that comparison should be taken with a grain of salt.

I still feel like I'm rusty in actually writing the code itself (yes, I realize it's only been 2.5 weeks) and there's a chance that I'm just cowering in algorithm design. But I definitely know that thinking about how to take a single, simple problem and finding ways to expand it and working through the possible solutions is my absolute favorite.

Jesse suggested I pick up Programming Pearls by Jon Bentley. It has useful tips and exercises that encourage you to thoroughly think about the problem. I'll try to record any of the pearls I pick up from the book.

Refactoring

I gathered a few refactoring tips throughout the day and from the web. Most of it just made me want to spend a lot of time really understanding a single concept and take part in free-form learning, aka 'running down the rabbit hole,' but Shereef encouraged us to focus on breadth, not depth for the time being. Figured I'll pick up more depth on my own time this weekend. Let's hope my confidence can play catch-up.

Two major notes:

1) List all your goals (preferably in order) for the code, estimate how long it will take you, and appraise whether that time is worth the effort right now. The last task seems to be the most difficult.

2) Refactoring allows us to think of the problem in a multitude of ways. Obviously this is incredibly useful. We understand the scope of the problem better as well as where our skill level lies. I'm trying to make mental (and physical) notes of what I've learned each time I refactor. I figure my future self will appreciate it.

So, refactoring doesn't just refer to code, but also refactorng how we think about the code. Being aware of how we moved from step to step and what we learned in the process is just as important as trying to build cleaner code.

"The modern man thinks that everything ought to be done for the sake of something else, and never for its own sake."

- Bertrand Russell

#dev bootcamp

Day 3 - Roy Bahat

Roy Bahat, President of IGN Entertainment at News Corp., talked to us about engineering, education, models of work, and his thoughts on the future of tech.

Some take-home points from his talk:

1) Focus on creating and building as opposed to the rules.

2) Don't be afraid to take the road less travelled.

3) The model of work, jobs, and resumes is, for the most part, broken these days.

Mental note: Pick up Paul Graham's Hackers and Painters: Big Ideas from the Computer Age

*Big thanks to Robert for talking about some topics in computational complexity with myself and Sung late last night. Makes me want to learn more CS theory after the camp.

(Will edit/update later)

#dev bootcamp

Pair Programming & Javascript

The title of this post is already overwhelming, so I'll stick with the most important points that I've learned from my first two days at DBC.

Pair Programming:

a) Sometimes you're slow, sometimes they're slow. Get used to it. Learn from one another. Energy levels will change throughout the process; feedback is essential.

b) Pair programming takes advantage of our inherent sociality, something that often gets lost and misshapened. That said, moderation is key; coding on your own is essential.

c) Did I mention that feedback is essential? According to Shereef, most problems in the world are due to broken feedback loops. This immediately makes sense, but I'll internalize it in time.

Javascript:

a) According to Marcus, most online resources for JS are "wrong." Will verify when I learn more.

b) More to come once my JS cogs aren't so rusty. Speaking of rust that I'm avoiding but need to take care of: http://yuiblog.com/blog/2007/01/24/video-crockford-tjpl/

DBC & Other Learning Tidbits:

a) While learning, endurance is usually important. Biking up and down a hill everyday has been a lesson in this.

b) This is a big group, but I'm usually at my best in small groups or one-on-one. One foot is definitely inside the panic zone. This is a good thing.

*c) While pairing with Noah yesterday, drafting a few solutions to the Pig Latin exercise made my heart soar. Talking about the code, finding new ways to think about the code, and thinking about thinking about the code is exactly the environment I was not getting while learning on my own. I usually avoid using this, but it just feels so right here: <3

#dev bootcamp

Gettin' It

Although I started dabbling in Python about a year ago, there was a tipping point that increased my desire to deepen these skills.

While working as a research associate at the University of California in San Francisco, the postdoc I was working under gave me the task of capturing still images from a microscope and analyzing them. With his minimal coding skills, he developed a simple program that made my task incredibly easy and quick. Soon enough, I developed a beginner's appreciation for the program that he created and I immediately became excited about the potential of solutions that even basic programming skills allow for.

After attempting to learn on my own using a variety of resources, I realized that an immersive learning environment would remove the roadblocks I kept encountering. For a month or so, I spent some time asking myself serious questions (kind of like the ones couples ask to each other before they decide that they want to get married) about what I really wanted. I applied and was accepted to Dev Bootcamp in San Francisco and Code Academy in Chicago. The structure of Dev Bootcamp, Shereef's enthusiasm, and the plethora of SF resources made my decision easy.

I will chronicle my projects, experiences, and reflections at Dev Bootcamp here.

Feedback is welcomed.

"You should be gettin' it, everything you want/ everything you dreamed of"

http://www.youtube.com/watch?v=2u3euxaxqXE

#Dev Bootcamp

Trending Blogs

Recently Viewed Blogs

Tripta Gupta