Who Can Program?
-
Bill Gates thinks you show the skills in the first 3-4 years and that pretty much determines if you're a great programmer or not. Jeff Atwood at CodingHorror.com thinks it's true as well and offers some insights into that if you read some of the related blog entries.
I tend to agree. I'm a mediocre programmer. I know how to program, can compile programs, I know linked lists, pointers, sorts, can call a method or write a class, but I don't love it. I don't spend spare time writing code, at least not much. I can knock out simple utilities or quick fixes, but I don't really have a passion for it and it makes me a good, but not great programmer.
And I agree that's not likely to change. I could really buckle down and I think in the short term, maybe a few months, I could do a better job, but not orders of magnitude better and I'd get tired of it pretty quickly, so it's not a great career path for me.
So are DBAs the same? Do you "get it" or not get it? I think in some sense it's true. I've worked with lots of programmers and many of them just don't get "sets" of data and how to work them. Sure they can move through a result set, but they don't really grasp what it means to join two sets of data and how you manipulate it. Often this shows up in outer joins, but sometimes grouping and ordering operations confuse them.
I do think that you can learn to be a better DBA, however, and learn how set operations work. I think that MDX, however, presents a whole new level of learning. Just understanding how more than 3 dimensions might fit together is beyond most people and I'm not sure how well you can develop skills in this area.
One thing I don't agree with in Jeff's article is that there's no work for average programmers or that all the jobs will get outsourced. I think salaries might stagnate, or possibly go down, but it will still be a good way to make a living from lots of companies that would like to have someone onsite and own their own code.
-
I think you have to be careful as to how you define a great programmer. I know people who can put amazing pieces of code together and get the code to do really clever things.
All good and well, but is that code useful? Obviously, when the tricky stuff needs writing, you get these guys in to do it.
But what I have observed over the last 11 years is that these guys often need direction and to be guided towards writing code in a simpler fashion. Often people write complex code because they think they have found a cool way to get something to happen. Just as often, the approach to the code could have been simplified dramtically.
I think you have alluded to it with you statement about DBAs. Either you get sets or you don't. With programming, either you get what the problem is, or you don't. Too often programmers get stuck in the details of the code rather than the process they are trying to create.
You can teach an old dog new tricks when looked at from this perspective. Usually.
-
It's all relative I think. If you're working at a company and show some aptitude for programming, your coworkers may consider you to be a 'great' programmer. it's a case of 'In the land of the blind, the one-eyed man is king'. Sometimes thats how i feel.
-
I agree with the previous poster - I'm primarily a programmer who also has to do a lot of DBA stuff because we do pretty much anything and everything. I've been programming for nearly 20 years and in my experience programmers fall into several camps:
- The Miner - those who work hard at it, get satisfaction from solving the puzzles but in the end lack the extra bit of inspiration/knack required to ever be self-reliant fully rounded developers. These guys are very dependable and handy to have around because though they have their limitations they are reliable and deliver.
- The Hacker - those who can throw something together very quickly that basically works, will often be very cleverly done, but will lack the integrity, quality and robustness that you need for software that has a shelf life. Nice to have about when you need some nut cracking but then take what they produce and make it viable.
- The Finisher - often a little bit slower than most, these guys cross every "t", dot every "i" and deliver software that pretty much gets through testing unscathed. Do what it says on the tin - nice to have as a last line of defence.
- The Drifter - the sort of person who actively looks to work in large teams with little autonomy on projects where they'll never get measured and where any fallout from disasters is shouldered by management or equally applied across the whole team. These guys naturally tend to drift into government departments and very large companies with leviathon computing departments.
- The Talkers - they know a moderate amount about pretty much everything and sometimes become expert in the theory of one or two aspects - their main attribute is they can talk, present and generally create the facsimilie of knowlege. These guys pretty much always become "Consultants".
- The Analyst - as the name suggests they are in the wrong job - very good at working out how to do something but not necessarily the person who should DO the doing...
- The All Rounder - probably less than 5% of all programmers fall into this category. Skills in design, DB, UI, coding, documentation - you name it they can do it. The sort of person you can give a one page spec to and they can do it all and do a good job. These are the guys who tend to form their own software houses or get employed by smaller organisations who can't afford the overhead of employing 10 programmers for every 100 lines of code.
-
Good topic Steve.
This argument has been posed in many ways. Joel Spolsky and Eric Sink went a round on this topic a while back.
My two cents: I think the software solutions market is dynamic enough to allow for differing skill sets / levels and their accompanying personalities. Quantifying this is quite the challenge indeed.
I liken it to a baseball team. From the perspective of a single game's defense, you may have a guy that stands in center field all day and handles two deep fly balls and another guy who pitches 7 innings. Quantifying that, one may look at the pitcher as being much more valuable - and this may be accurate.
Taking a look at the offense of that same game, the pitcher may bat four times, make it on base twice - advancing runners, and even bat a runner home. The centerfielder may strike out three times but then smack the home run that wins the game.
How do you quanitfy this? How do you evaluate the peformance of these players on this day? How much do you consider past performance and potential?
I don't know all the answers to these questions, but I know they're important questions. My context for the answer is: It depends on who I'm playing (the competition).
This is where good management comes in. And good management is part art and part science - but leans heavily towards art.
Truly great baseball managers know what to expect from their team. They know the strengths of the individual players. More than that, they know how different players are going to interact on the field.
Truly great software managers know what to expect from their development team. They know the strengths of the individual coders. More than that, they know how different developers are going to interact on a project.
I believe the essence of the argument between Joel and Eric can be boiled down to perspective: Joel's perspective relates more to individuals carrying the team - superstars ("soloists"); while Eric's relates more to the team performing at a level that exceeds the sum of the individual contributions ("choir").
This is important: Both types of teams win championships.
This is also important: There are a lot more "choir" combinations that lead to success than their are "soloist" combinations.
This is perhaps most important of all: The key to success in both cases is leadership.
:{> Andy
Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics
-
Great article! I completely agree. I went to college with 10 friends and we all finished up wtih completely different abilities even when all trained the same way.
One guy is an absolute burrower. he would get a problem and just dig and dig and dig, and it didnt matter how complicated it got, he would get it sorted. pretty good all rounder actually.
One guy is super fast at creating an app, and uses any way he can to minimize the amount of code he uses, but isnt very good at creative solutions, or looking at stuff in the wider scheme of things.
I would get a problem and if i couldnt understand the way others do it, i will simplify it and do it my own way, even if it means a lot more code. I have a wider field of view and can use more creative solutions.
Thats just 3 people and are all incredibly different. we all have completely different jobs, im an analyst and a db dev/admin,doing a small bit of everything, working in a team, but a master of nothing the other two are devs, the first guy in java and c++ ( wouldnt ya know it) working atonomously, the 2nd guy is in web development doing XP programming which suits him perfectly.
Different traits, different talents, and different jobs that suit each of us. So i think this proves there is a place for all levels of programmers, and all can work together successfully
-
Hard topic to quantify. The one point I'd add is that mediocre or not, you basically have people falling roughly into two groups. Those that have a year or two of experience multiplied by some factor (we've got people who've "worked in the business for twenty years" still doing things EXACTLY as they did them 18 years ago). They're followed by those who are constantly growing and expanding so that their experience really is experience. You can constantly grow and expand and still be mediocre and you can grow & expand and be wonderful. You can't really be a great programmer with no growth though.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning -
Walt Disney said that in designing projects you needed three types of people:
Engineers - someone to turn the idea into the necessary parts
Creative people - someone to have an idea
Critics - someone to see the errors of the plans
Sometimes one person can fill all these roles and turn out perfect code. These people are most successful. Often times most of us only can fill one or two of these roles and must rely on others to review our code and point out our errors. Personally I think 3 - 4 years old is a little young to determine if you have the skills to be a programmer, or anything else. People tend to develop at different speeds and with different experiences. But there are people I've worked with who are definitely in the wrong field and will never be great.
-
I like this list! I work at a small university so I'm going to put myself in category 7, haha.
-
I think it's time for a DBA caterogy survery.
-
What's MDX?
-
A great programmer has to be able to manipulate data in the database and display that data simply to the user. Programmers that are afraid of SQL are surface programmers and should be used to test and clean up applications.
There is plenty of room for both types of programmers but the salary difference between the two is enormous.
-
Some great comments and things to think about. I was really interested to see what you might think because I think we'll always have jobs.
MDX is a language for cubes and analysis services, multidimensional queries, that is similar to T-SQL, but used by the BI folks.
-
From Steve's article "...from lots of companies that would like to have someone onsite and own their own code."
Danger Danger Danger
We use a medium sized software package that is SQL based. We had an authorized 3rd party company modify some of the source code to better suit our needs. Works great. The downside is that when the software updates come out, they would have to run it against a copy of our enhancements to make sure nothing breaks. This delays the update, no big deal but adds a layer of complexity.
That 3rd party company is now gone. We can no longer safely apply updates and no body else wants to touch the modifications. I'm not a programmer but I can recognize that the software package is complex and appears to have been updated from Cobal/Progression and then cobbled together to work with SQL. Extracting data can have a steep learning curve for some parts.
Lesson learned. We should have not chosen the method to modify the program but at the time, it was and still is the only choice.
Which brings me to Steve's comment. A smaller company may "love to have a programmer" on site. But they might not be too happy when that person moves on and didn't document the work well. Or, once the company has what it needs, the programmers employment is over. Either way, that problem could follow a person for a long time.
Unless you want to be a consultant and build a business maintaining all the work you do, then programming for smaller companies may not be a wise career path.
-
"A smaller company may "love to have a programmer" on site. But they might not be too happy when that person moves on and didn't document the work well. Or, once the company has what it needs, the programmers employment is over. Either way, that problem could follow a person for a long time."
Excellent point Bob. It's definitely a two-way street. I think companies (small and large) are sometimes short-sited or oblivious of the value of domain knowledge possessed by software professionals in their organization.
:{> Andy
Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics
Viewing 15 posts - 1 through 15 (of 25 total)
You must be logged in to reply to this topic. Login to reply