Juixe Techknow

There are a few things that every developer has to day in and day out every week. I like working on new projects and new features but the mechanics of software development can feel like a routine. Here my todo list that I do just about every week…

• Checkin early, checkin often, sync everyday (Perforce).
• Run build (Maven).
• Add and run tests (JUnit).
• Refactor, reduce, simplify API (Eclipse).
• Profile code (YourKit).
• Analyze source (FindBugs).
• Clean up comments.
• Clean up warnings.
• Update wiki (MoinMoin).
• Remove dead code.
• Code review.
• Write TPS reports.
• Rinse and repeate.

Did I miss anything? What is your developer routine look like?

Memes involving programming languages and technology in general are not updated once there is a new release. Java has been dogged with the perception that it is slow since Java 1.1, over ten years ago. Programming languages such as Perl, PHP, and Ruby have their share of FUDy memes. Here is a short list of programming memes…

• Java is slow.
• Perl is dead.
• PHP is a not a proper language.
• Ruby does not scale.
• JavaScript is for script kiddies.

I came across the Twitter hashcode #twitcode that folks where using to tweet code that fit under 130 characters. After searching for more twitcode here are the ones I thought where the best, as of this writing.

• @gsale: if(apathetic){System.out.print(“Don’t care.”)}elseif(ignorant){System.out.print(“Don’t Know.”)}else{(System.out.print(“tweet”))}
• @bifethewise: $madness ? $this.is = MADNESS : $this.is = SPARTAAAA;
• @eggsy84: function dance(year) { if (year == 1990) { stop(); hammertime(); } }
• @fhussains: On Error GoTo HELL
• @TurkoAmericano: if (you.AreHappy && you.KnowIt) you.ClapHands();
• @longhorn2005: // TODO: Don’t forget to write something funny…like oh my GOD somebody is trying to use me.!! CODE RED, I REPEAT CODE RED!
• @misspentlife: double evil = 666; double money = Math.Sqrt(evil);
• @mmetzger: Little late to the game but – public bool got(baby b) { return b.contains(“back”) ? true : false; }
• @dbutscher: if (we.WantTo) {we.CanDance() && we.CanLeaveYourFriendsBehind()}
• @yboyacigil: to.be() || !to.be()
• @purpig: if ((drinking)); then cat /productivity > /dev/null 2>&1 fi
• @Iggyhopper: if (onGrass) Yell(“GET OFF MY GRASS”); else Sleep()
• @dbutscher: if (you.Want(this.Body) && you.Think(this.IsSexy)) {baby.Notify(this);}
• @dbutscher: if (!atFirst.Succeed) {try {again} }
• @captaincrash80: if (drinking) { drive = false; } else { you.inJail = true; }
• @Tchovis: while(!drunk){ if(party.start){drink(beer)}else{drink(vodka)}if(vomiting) drunk = true; )
• @kronius: SELECT thoughts, dreams, ideas FROM head WHERE allThis LIKE ‘work related’ ORDER BY quality;
• @ltlfrari public int WhatIsTheMeaningOfLifeTheUniverseAndEveryThing() { return 42; }
• @TurkoAmericano: public int GimmeFive() { return 5; }

Search for the term ‘better developer’ and you find nearly 70 million results. It seems like everybody has an opinion on how to become a better developer, even the bad developers will tell you how to be a better programmer. After reading many of these programming self-help articles on being a better developer I found that the core message was all the same! If I could boil down the advice of all these results into a succinct list of how to be the best developer we are left with the following…

• Read Everything
• Learn Fast
• Practice What You Know
• Try New Things
• Strive for Simplicity
• Write and Teach
• Assume Nothing
• Question Everything
• It is Not Personal
• Know Your Tools
• Rinse and Repeat

There is no one Golden Rule for becoming a better developer. Instead of single rule or a unifying theory of software development we have a set of core beliefs and best practices.

Here is the insight from many other developers on how to be a better software developer. In reading their advice, think what is universally true for all developers. What can we learn from each other, no matter the development platform or programming language we use?
Continue reading

Effective Java was the first book I’ve read whose table of contents had read like programming commandments. The rest of the book provided commentary and examples, but the section headers read like axioms to program by. I found a similar book in 97 Things Every Software Architect Should Know. 97 Things is a collection of 97 short essays from a number of architects on topics such as soft skills, leadership, and software architecture. The table of contents for 97 Things also reads like commandments or axioms.

97 Things Every Software Architect Should Know is a collaborate effort from numerous contributors. The project wiki is available here. Below are 101 axioms taken from the different essay titles from the project. The axioms have been rearranged from the original order provided online to provide context, and in cases edited for legibility.
Continue reading

I would not recommend the same org chart to two different companies even if they had the same number of employees. The organization of a company should grow organically based on a number of unique conditions to each company, such as the industry best practices, company culture and temperament, number of clients, client schedules and product life cycles. Companies need to recognize that they also go through growing pains, how you manage a company with 10 employees is different when the company grows to 20 and much more when it grows to 100. In a company of 10, you can just walk over to the cube next over and resolve a design issue. In a company of 100, you will have to create a project schedule, email participants, schedule conference room, schedule meeting, reschedule meeting, debate architectural constraints before you can resolve the same sort of issue. The amount of communication required grows exponentially to the number of participants involved.

Another key element in the team dynamics of any organization is the leadership style. A team managed by a micro-manager will evidently require more management, metrics, and external motivation such a money and perks. Teams that are made to feel as active participant will take more ownership in the project which gives them an incentive to make thoughtful decisions.

This is a key reason why I don’t believe in cookie cutter business plans. You can copy a product feature by feature, but it is that much more difficult to replicate the staff commitment, work environment, and team dynamics.