2012年3月31日 星期六
2012年3月11日 星期日
Programmers are born not made
Programmers are born not made
Jan 05 2012
Programmers are a special breed, good programmers especially – our craft is more an art than we like to admit when trying to wrestle it into a Hard Engineering Discipline ™. It’s actually more like mathematics, music or the wizardry Kaylee does in Firefly.
Good programmers have a special feel, a talent that is difficult to explain and even harder to attain.
A few weeks ago @zidarsk8 came rushing to me “Dude! There’s this guy! I’ve been teaching him coding! He’s already better than me! Hasn’t even heard of a variable before a month ago! It’s so frikkin’ awesome!”
He made me promise to blog about it. Why is it some people just get it? What’s so special about them? Can anybody be taught to program or does it really take a special breed to become even a competent programmer, let alone a good one?
I remember tutoring a high school kid about a year ago. About to fail his programming class (CE high school, we have those), he came running to me. In a month I was to teach him everything I know, or at least enough to pass the class.
Come end of the month and he knew everything about loops, variable assignment, even understood that functions are packets of code that can do stuff. My parting words to his father were “Yeah, he knows everything. Just needs a bit of practice to get it.”
I doubt he ever passed the class. Or if he did it was the teacher’s mercy … and that teacher isn’t very merciful from what I remember of her in my high school times.
But this isn’t just because I’m a bad teacher – others came to me after that one kid on his recommendation and I got a “Thank you! I bloody passed! yay!” email from all of them – there are people who simply aren’t programmers. Never will be programmers. Not even mediocre ones.
The non-programming sheep
Jeff Atwood wrote about Separating Programming Sheep from Non-Programming Goatsin 2006 where he mentions a study that claims to have found a test to predict future programming ability.
The test is really simple:
a = 5 b = 20 a = b What are a and be now?And some more questions like that. Only 44% of the students formed a consistent mental model of assignment – even a wrong one. The rest failed or didn’t answer the questions.
Worse still, after a semester of learning to program, the numbers were the same. Only 44% of the students understood how assignment works.
Some people just dont get it. Apparently.
But I think there’s an even simpler test ->
Passion.
Sometimes when you give an impressionable young mind (anybody deciding to learn to code, age is irrelevant) two tools and a problem, they will use the two tools to create four more tools. Then they will get on the internets and find some more tools … soon they have twenty tools and what was the problem you wanted me to solve again?
That’s passion!
Pure unadulterated passion for programming. When you can be fascinated, even excited, about this stuff without a need to solve a problem. Hell, even if you are solving a problem that you know is a meaningless exercise … that’s where greatness lies.
It doesn’t matter what age you started coding at – many studies have shown experience is not a predictor of quality in our world – what matters is that you have a passion for this stuff.
Because if you’ve got the passion, then you probably have everything else you need as well.
Related articles
- Programmers are fucking lazy (swizec.com)
- Becoming a better Developer (bob-roberts.net)
- Programmer – The Best Professsion? (jaredcosulich.wordpress.com)
- What’s in a name? Programmer or Developer (bob-roberts.net)
- Today a programmer was born. And you are my mother. (news.ycombinator.com)
---
Need a freelance developer? Email me!You should follow me on twitter
http://swizec.com/blog/?p=3369">20 responses so far
What makes a great software engineer?
A couple weeks ago, a presentation made the rounds online about Netflix culture. The presentation featured the many benefits of working for Netflix and how the company goes about hiring (and firing) employees. While there was a lot of information about Netflix’s treatment of employees, which clearly makes Netflix an attractive place to work, the missing part is a list of employee expectations. The beginning of the presentation touches upon the company values that point in the direction of expectations but doesn’t go far enough to lay those out.
I don’t work at Netflix, of course (I work for Yahoo!), but I feel strongly that what makes a great employee and a great engineer is the same regardless of where you work. There are a few things that great engineers always do.
Always do it the right way
One of the challenges of software is to learn how to do it the right way. The right way is different depending upon what you’re working on and who you’re working for. Exactly what “the right way” consists of is less important than doing it that way all the time. Junior engineers tend to have the most trouble with this, but it does happen with senior-level people too. There’s an “emergency” project, or something that seems so different that it must have its own set of rules. That’s bogus. Good engineers know that the right way applies to all situations and circumstances. If there’s not enough time to do something the right way, then there’s really not enough time to do it. Don’t make compromises, the quality of your work is what ultimately defines you as an engineer. Make sure that all of the code you write is done the right way 100% of the time. Expect excellence from yourself.
Be willing to suffer
This may sound silly, but good engineers are willing to suffer for their work. Show me a great engineer and I’ll show you someone that has, at various points in his or her career, spent days trying to figure out a problem. Great engineers relish the challenge of a problem that keeps them up day and night, and knowing that it must be solved.
Not-so-great engineers call for help at the first sign of trouble. They routinely ask for help whenever something goes wrong rather than trying to fix it themselves. Their favorite line is, “can you look at this?” Great engineers first and foremost want to solve the problem on their own. Problem solving is a skill, a skill that great engineers take seriously.
Good engineers become great engineers by suffering. Suffering means not asking for help unless you absolutely cannot handle the task. Asking for help is a sign of defeat, so ring that bell infrequently lest you draw unwanted attention to yourself. Be willing to suffer. Spend time toiling over the problem. That’s how you learn.
Note: I am not saying that you should never ask for help. I am saying that you should try to accomplish the task on your own first, and if you get stuck, then ask for help. Don’t simply ask for help every time without first trying to solve the problem yourself. Chances are, you’ll find that you could have figured it out on your own once you know the answer.
Never stop learning
Any engineer who claims that they don’t need to learn anything new is not someone with whom I’d like to work. In some careers, you can get away without learning anything new for years; technology changes too quickly to not pay attention. Your employer is paying you for your expertise and if that expertise goes stale, you become expendable. In order to be a great engineer you must first admit that you don’t know everything, and then you must seek out more knowledge in every way you can.
Identify someone in your current company or organization from which you can learn and attach yourself to him or her. Ask for advice on complex problems to see how they think. Show them solutions you’ve come up with and ask for a critique. If you can’t identify anyone in your organization that can serve as a mentor, then either you’re not looking hard enough or you’re at the wrong company. If you can’t grow in your current job then it’s time to look for another.
Read blogs. Attend conferences. Go to developer meetups. Great engineers never stop learning.
Share your knowledge
There are some who believe that their sole value is their knowledge, and by sharing that knowledge they therefore make themselves less valuable. Nothing could be farther from the truth. What makes you valuable is not your knowledge, it’s how you make use of your knowledge to create value for your employer. How better to create value from your knowledge than to share it with others?
I’ve interviewed at companies where hording knowledge seemed deeply-rooted at the organizational level. In that type of environment, a fierce competition develops between co-workers, and this opens the door to politics and backstabbing. I don’t want to work in an organization like that. You can’t learn if everyone is keeping information to themselves.
Great engineers want others to know what they know. They aren’t afraid of losing their position because someone else can do the same thing. Great engineers want to see their peers succeed and grow. Organizations rally around people who share information, and as they say in sports, people who make other people on the team better.
Lend a helping hand
Great engineers don’t consider any task to be “beneath” them. Always willing to lend a hand, you can see great engineers helping out junior engineers in between doing their own work. If something has to get done, and no one else is able to do it in time, great engineers volunteer to take on the work. They don’t scoff when asked to help on a project, whether it be small or menial or low-profile. Great engineers are team-focused and therefore are willing to do whatever it takes to help the team. Whether that be writing 1,000 lines of code or editing an image, great engineers jump at the chance to help out.
Take your time
Great engineers aren’t born, they are made. They’re made by following the advice in this post and by hard work. If you’re just starting out, there’s still plenty of time to become a great engineer. Patience is key. You don’t become a great engineer over night. For some it may take a couple years, for others it may take ten. There’s no one keeping score. Strong organizations recognize when someone has the potential to be a great engineer and will guide you along. You prove yourself through your work and how you make your team better. Focus and self-discipline go a long way towards becoming a great software engineer.
Update (5 Sep 2009): Added disclaimer paragraph to “Be willing to suffer.” Seems like people are greatly misunderstanding my point.
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
2012年3月7日 星期三
2012年3月6日 星期二
You don’t really want a million dollars
This morning, I was feeling a little stir-crazy from being cooped up in my office, so I decided to stretch my legs and go to the cornerstore down the street. I got a bag of chips and while paying, asked the guy behind the counter how he was doing. He responded with a heavy sigh and said “Tired, man. I need a million dollars and i need to travel. Things are bad right now, man.” He made a tired half-joke about how maybe he’d win the lottery scratcher this week.
He didn’t offer any more info and I didn’t want to pry, so I told him that I hoped things would pick up for him, paid for my chips, and left. Walking home, I couldn’t shake a feeling of sadness about the conversation. I know what it feels to have life kick you in the teeth, and feel like you just need to get away from everything. How many times have I thought to myself “If only I had a million dollars.” However, I’ve come to realize that the wishful desire to have an arbitrarily large amount of money is a reflection of lazy thinking.
That sounds harsh, I know. Don’t get me wrong: I sympathize with this guy and I’m not trying to be dismissive of his situation. And I don’t even know what his situation is; maybe he really does need a million dollars for medical bills or something. But I doubt it. What’s more likely is that he’s just down on his luck, struggling through a rough time, and sees a large pile of cash as the solution.
In The 4-Hour Work Week, Tim Ferriss talks about an investment banker friend who was working 80 hours a week for a big payoff in ten years, when he’d be making several million dollars per year. When Tim asked what he’d do with all that money when he got it, his response was “Take a trip to Thailand.”
The sadness of this answer is profound; too many people have come to believe that it will cost them millions to really live the life they want. How many people do you know who wish they had a million dollars? Probably more than you think. But the sad part is that most people don’t even want a million dollars; they want the things they think a million dollars can buy.
The biggest thing on that list: freedom.
But freedom doesn’t cost a million dollars. You can change, learn to live on your income, save money, travel on almost nothing, live abroad, follow your dreams. The world is full of more and more possibilities every day. More and more people are discovering freedom and opportunity beyond what they really thought was possible. Gary Vaynerchuk does a fantastic job of detailing these opportunities in Crush It!.
I spent months traveling around southeast Asia on a shoestring budget. I work for myself, when I want, where I want, on what I want, and I’m not wealthy by any stretch. Ironically, I’ve seen huge increases in my earned income, passive income, and net worth in the three years since I took the risk of breaking free and trying to create the life I want instead of waiting for it to come to me.
Here’s the reality: if you’re not the type of person who can create freedom without a million dollars, you probably aren’t the kind of person who will get a million dollars. Because both take a certain kind of ingenuity, discipline, and proactivity that most people seem to lack.
If you’re really interested in knowing what the journey looks like, check out Crush It! and The 4-Hour Work Week. You might not find everything in these books to be useful to your situation, but I guarantee it will spark some curiosity and new ideas in you, no matter who you are. I think I’ll give a copy of each to the guy around the corner next time I see him.
You might also enjoy:
- How a Barista and Losing a Quarter of a Million Bucks Taught Me to Ask for What I Want
- How to retire at 30 on $1 million
- $1.2 million for Ron Paul in 9 hours
- How to Become a Billionaire
- The top ten posts of 2010 on RyanWaggoner.com
You should subscribe and follow me on Twitter here.
well said.
2012年3月1日 星期四
NosqlDefinition by Martin Fowler
NosqlDefinition
9 January 2012 tags: database
As soon as we started work on NosqlDistilled we were faced with a tricky conundrum - what are we writing about? What exactly is a NoSQL database? There's no strong definition of the concept out there, no trademarks, no standard group, not even a manifesto.
The term originally surfaced at an informal meetup on June 11 2009 in San Francisco organized by Johan Oskarsson. At the session there were presentations from Voldemort, Cassandra, Dynomite, HBase, Hypertable, CouchDB, and MongoDB. The term caught on rapidly and few people would argue that only the databases mentioned at that meeting should be called NoSQL.
Indeed there's often a twist in the name itself: many advocates of NoSQL say that it does not mean a "no" to SQL, rather it means Not Only SQL. On this point I think it's useful to separate an individual database from the kind of ecosystem that NoSQL advocates see as the future. When we say "x is a NoSQL database" I think it's silly to interpret NoSQL as "Not Only" because that would render the term meaningless. (You could then reasonably argue that SQL Server (say) is a NoSQL database.) So I think it's best to say a "NoSQL database" is a "no-sql" database. You should separately interpret the NoSQL ecosystem as a "not only" - although I prefer the term PolyglotPersistence for this usage. [1]
Even with this matter out of the way, it's still not easy to define a NoSQL database. Does any database that doesn't use SQL qualify? How about older database technologies such as IMS or MUMPS? How about a relational system that didn't have SQL (such as the early Ingres)? What happens if someone manages to bolt a SQL interface onto one of the original septet?
So for our book we took a view that NoSQL refers to a particular rush of recent databases. Some characteristics are common amongst these databases, but none are definitional.
- Not using the relational model (nor the SQL language)
- Open source
- Designed to run on large clusters
- Based on the needs of 21st century web properties
- No schema, allowing fields to be added to any record without controls
While I'm used to the blurry lines of definitions in the software industry, I confess my heart sinks at yet another one. But the important thing is that these databases provide a important addition to the way we'll be building application in next couple of decades. A lack of a clear definition will be no more than a gnat bite on their future successes.
1: If we take the "not-only" interpretation, then we should write "NOSQL" rather than "NoSQL". I almost always see it written as "NoSQL".
