Reflections on 10 Years of Development

1. Anyone can become a star programmer, it just takes some longer than others.

2. Your keyboard matters, Good typing habits matter.

3. Be balanced, don't believe everything you hear or read, including this. Come to your own conclusions, know that nothing is ever black and white. Don't dismiss the bad ideas, and don't trust the good ideas.

4. Process can be a "good thing" ( Agile, Extreme, Scrum, etc.. ) But it doesn't make or break your project. People make or break your project.

5. Don't choose a language based on how fast it is but instead, how fast you can develop with it.

6. Don't choose a language because there is a large pool of developers familiar with that language. The larger the pool of developers the more likely you will be temped by a fancy resume and hire a mediocre programmer. However if you dip into a smaller pool of developers you know the developers in the smaller pool are there, not because it will look good on their resume, but because they enjoy working in the language. This increases the chance you will get a star programmer.

7. The programmer is greater than the language. This means you can give any language to a great programmer and you will get great code. The opposite is not true, you can't give a great language to a mediocre programmer and expect great code.

8. Your Language matters. Giving the right language to the right programmer can have a huge impact on the success of your project.

9. Not all languages are created equal. Some languages are more powerful than others. The problem is not with the languages, but the people that use them. If we see a language that is less powerful than our favorite language X, we know it's less powerful because is doesn't have feature Y. But if we see a language that is more powerful we don't recognize it as more powerful. We just see a language with some strange syntax and some extra cruft added on. We reckon that it's just as powerful as our language X, but nothing more.

This is partly because we are creatures of habit, but mostly because we have trained our brains to *think* in our language of choice. People don't think in terms of feature Y if their language doesn't support it. hence its not necessary nor needed. This means you could stumble upon the language equivalent of a super weapon, but never know it.

10. Don't think your so special. Don't get me wrong, every one needs to think they are special, but programmers take it to the next level. It's not enough for us to think we are special, we have to display that individuality in the programs we write. Hence we write tools tailored to only our special needs and tend to write our programs in a style that is uniquely ours.

This is the central idea behind Perl, although most people don't know it. Perl allows the programmer to write their code and tools in the most beautiful or bizarre fashion. This only fuels the idea that we are special because we wrote this thing in such a way as only we easily comprehend it. We create these incredibly complex 1 liners or beautifully efficient terse code and we pat ourselves on the back for creating this code that takes any other programmer 20+ minutes to comprehend, We are proud of this because it means we are special and more intelligent than the other guy. Because we *get it* and they don't.

Although this allows us to show off our individuality and show how clever we can be. It makes collaboration difficult if the other programmer gets a head ache deciphering our code. In the end, he won't want to work with us, and will routinely suggest the code should be re-written. Sometimes even naming conventions such as CamelCase or under_score will cause other programmers to request a re-factor. Because it doesn't match the style which defines their individuality. Which leads me into Number 11.

11. To much flexibility can be a bad thing. People who argue that flexibility is a virtue enjoy being special. They revel in the fact they have choice. The truth of the matter is people will usually make 1 choice and then stick to it. ( For example: CamelCase vs under_score, or TABS vs Spaces ) But it doesn't stop there, what about design choices that will effect the entire life of your project?

Flexibility gives you a plethora of choices, but how do you know which one to make and wont bite you down the road? This delema is most felt by the newbie programmer. A new programmer is more likely to make incorrect choices than correct ones. Why introduce this delema at all? Why not give the programmer 1 set of tools that encourages the programmer to make correct choices. I'm not suggesting there is only 1 way to do things, I'm just suggesting there can be reasonable defaults that nudge the programmer into doing things correctly from the ground up.

This is one of the great strengths of ruby on rails. The programmer doesn't have to make upfront choices and wonder if the choice he made at the beginning of his project is going to bite him as the program scales. He knows the rails "convention" scales, so his project will scale as well. Even tho he might not be familiar with the design patterns behind rails or why this convention scales and another doesn't. He can rest easy knowing that early poor design choices will not leave him wishing he could just re-write the dam thing.

12. Never stop learning. Once you stop learning you die. Seriously... Programmers are like trees. Trees are always growing, they never stop. If a tree stops growing it dies, becomes stiff, brittle and collapses. Programmers are the same, once you reach a point where there are no new ideas that can effect you and your programmer experience. ( AKA you know it all, been there done that ) you become stiff and un-movable. You become the guy no one wants to work with, the OLD guy set in his ways with no room for improvement. Avoid these people at all cost, their poor attitude is infectious.

13. Sleep. There is a myth among programmers that the guy who pulls the all nighter is the programmer equivalent of a bad ass. In the short term you may make significant progress in a 24 hour span, but that is not going to make up for the productivity you will lose recovering from sleep deprivation during the next few days and weeks. A good night sleep is good for your brain and your arteries, especially as you get older.

14. Do something else besides program. I can't tell you how many times I've been enjoying a secondary activity and then Bam, the eureka moment hits. Preforming other activities besides programming exercise different sections of the brain. This not only makes you a more rounded individual but also a better programmer.

There is no vudo

One of the newet members of the development team at work reminds me of myself when I was new to the development scene. I'll see him mulling over a bit of code or system issue that from his point of view *should* work, yet does not. This usually leads him to the conclusion that the system is preforming some kind of unknown Vudo and that there is in fact nothing really wrong. This is beleived in spite of the the fact he is getting incorrect results.

The truth is, and I came to this conclusion only thru experience; there is no Vudo. The effect does in fact have a cause. You only have to follow the effect to it's logical source now matter in-conceivable the cause could be, it does have a cause; you have only to find it.

The skill you gain from this experience is the ability to diagnose that cause sooner than the guy next to you.

Wow... I'm getting old.

Old is new again

While browsing through some old chat logs I found this little gem

< brian > hey, please make sure to turn on updatedb in your build script. 
< thrawn01 > should be on by default, but I'll check.
** I sent some messages confirming its on as default on the new boxes **

< brian > life is filled with mystery
< thrawn01 > That is just a nice way of saying u were mistaken
< brian > so, your theory is that someone went to 
          prod4 and sat-svn1 and turned it off?
< thrawn01 > ninjas
< brian > stealthy root ninjas. very likely.
< thrawn01 > indeed.

I also found a qoute from stephen hawking

"The whole history of science has been the gradual realization that events 
do not happen in an arbitrary manner, but that they reflect a 
certain underlying order, which may or may not be 
divinely inspired"

I find that I would have to agree.

Ollie has a home (Kinda)

Ollie now has a home up at Google Code. Unfortunately Google code only supports the horrid SVN repository and not GIT. So I also created a git repository over at GitHub. Because I really dislike the Google Code wiki, I still have the Media Wiki hosted on nates box

So Google code

The Good

• Clean Interface
• Fast, Responsive ( unlike sourceforge )

The Bad

• No Git Repository Support
• The Wiki Markup isn't a flexable as MediaWiki ( Example: You can't keep a Camel Case from being a wiki link. Like when I list my Class Objects Utf8Buffer shows up as a wiki link and I don't wish it to! )
• The presentation of the wiki is not to my liking. You don't get a Wiki front page, instead you must select a wiki page to view from a list!

Summary
I think Google Code as alot potential, but still does need work before it becomes the 1 stop shop for open source code

C++ Library symbols

I've looked up this information enough I need to keep it in a place I will not lose it.

To get a list of all the C++ symbols in a dynamic library use 'nm' command. You can get a demangled listing of the symbols by using 'nm --demangle'

Output
symbol types: each symbol type is shown by a letter. If the letter is lowercase, the symbol is local. If the letter is uppercase, the symbol is global ( external )

nm - lists symbols from object files for each symbol the following is displayed:

• the value in hexadecimal
• the symbol type
• the symbol name

How long does it take to install an OS?

Apparently, 2 days...

Lets start at the top, Mix in a small army of new DL360 G5 servers from HP ( 7 Cores, 6 Hard drive Raid 5 arrays ) and Redhat Enterprise 5 and you get problems. Just before RPM installation begins, anaconda throws an exception and reports the following error.

SystemError: lvcreate failed for /dev/blah/blah
( 100 lines of Goo follow )

Day 1
Someone thinks it's a driver issue. Google reveled someone else seamed to be having problems installing their OS on the same hardware we had, with similar errors. I expend hours trying to verify the updated driver for the array controller was A - installed, B - used properly. Next we notice lvcreate and pvcreate are not included on the ramfs when we access the shell from the redhat installer. So we search for updated anaconda installers ( Still don't know how anaconda creates LVM partitions without lvcreate or pvcreate. "find . | grep pvcreate" returns nada ) I try some other stuff then go home.

Day 2
Brandon pulls the Firmware for the MOBO from the HP website and gets the OS to install. But when we try to duplicate that trick it doesn't work. We note the OS installed on the 200GB array, but not the servers with 600GB arrays. Retraced the steps taken on the 200GB array and duplicated them on the 600GB array servers.... nada. Next I notice a funny looking error at the bottom of the exception anaconda gave us. ( Not sure if it was there pre firmware update )

Read only file system /dev/hda1
insufficient free extents for VolumeVOL000, blah,blah

Google doesn't help much, but then it strikes us we might have encountered some max size of a LVM Volume. ::Google some more::

Synopsis
Turns out an "extent" is the size of a chunk of space allocated on a LVM Logical Volume. According to one site the max number of extents you can have on a single logical drive was 65,000 and if your extent size was to small it might put you over this limit. Anaconda figured we needed a 32MB extent size, What we actually need was 64MB extent. Why this is the case, I'm not entirely sure. ( When I get some more time I will append the answer to this post ). But getting the OS installed involves a 2 step process, 1) Update the firmware on the MOBO 2) Up the extent size of the logical drive using disk druid.

Google Interview Question

An interesting problem I ran across on a blog the other day.
Quote from the blog....

Given a function which produces a random integer in the range of 1 to 5, write a function which produces a random integer in the range of 1 to 7

This is well-known as one of the so called Microsoft/Google interview questions. There are million ways to solve it.

So here is my Take on the solution.

int rand7() {
return 7 / rand5();
}

You will only get 1 2 3 or 7 using this solution, but the requirements didn't call for uniformity.

More uniform would be

int rand7() {
return (( rand5() + rand5() ) % 7) + 1;
}

A friend of mine was confused with the modulus '%' in this function. The modulus returns the remainder of a division operation. The remainder of a division can never be greater than the dividing number ( in this case 7 ) which means % will always return a number between 6 and 0 ( 0 ... 6 ) which is also why we add a +1 to the result to get 1 thru 7