Juixe Techknow

From time to time I just blast tweets about software development, project planning, team dynamics, or whatever else comes to mind. Here is a synopsis of recent tweets and rants. If you want to follow the conversation follow me at techknow and I’ll be sure to follow back.

Programming

• Some people expand their mind, I scale and then shard mine.
• Scale your vision, your thoughts, and then yourself.
• Refactor, reduce, rinse, and repeat.
• Model your mind, debug your thoughts, and remove the printf statement from your comments.
• If you perpetuate bad code, you might be a bad developer!
• Code is about learning – If you are not learning you are doing it wrong.
• It is not that an artist knows his tools well that makes him great, it is that he knows his media! As programmers, what is our media?
• If the media of a programmer is the language, what is the media of the program user? The domain space? Should they be the same?
• I am dumbfounded by the amount of repetitive, tedious, and manual work a programmer will endure before they even consider automating tasks.
• Code talks, bugs walks.
• There is a thin line between a solution and a hack…
• The absence of a save button does not mean entities can not be saved.
• Less code is the best code.
• For any bug fix, all the debugging and all the time put into it is lost if you don’t add a test case for the root cause.
• JavaScript + jQuery UI + bookmarklet + PHP + Twitter API = tweetmark. I wrote a bookmarklet to bookmark URLs to @juixe.
• Don’t catch and release exceptions, exception handling is not a sport.
• My job is to make software easier done than said.
• DB Rule of Thumb: Don’t ever change the database schema without a second, third, and even fourth thought.
• There is no magic in software development! Files don’t delete themselves out from version control out of electronic spontaneous combustion.
• To avoid dubious verbose recursive repetition, variable names are not comments and comments should repeat variable declarations.
• Debugging is not just about code, debug your process and focus on what works and remove and modify that which doesn’t have positive results
• Just because you can teach end users new tricks does not get you off the hook from you learning to design an application with fewer tricks.
• Even when saying the same words, it is possible, and not unlikely, that developer understand features differently than what clients expect.
• Code can easily be refactored, but developer way of thinking is more difficult.
• In programming you have to think outside the box and outside the stack.

Continue reading

If you search for ways to become a better developer you will find nearly 70 million results. After reading as many of those results as possible and still learn something, I boiled down all the advice to the following general axioms.

• Read Everything
• Learn Fast, Learn Everything
• 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

The advice above can be used in just about any industry by anyone trying to advance in their career. This advice holds true whether your are a Ruby programmer or investment banker. The truth is that being a better students makes us better at whatever we do. If we learn how to learn, to see the patterns blindfolded, to navigate up and down the different layers of abstractions, to troubleshoot and debug code you never seen before, to ask the right questions at the right time… all these things help us write better programs no matter what language or technology stack you use.

That said, I wanted to illustrate these rules with more concrete examples specific to programming. Given a particular job title, say Ruby on Rails Developer, we can break down the above axioms to the following advice for being a better Rails developer…

• Read Everything
  • Download sample/Open Source apps
  • Dig into Rails source code
  • Read tutorials
  • Read books
• Learn Fast, Learn Everything
  • Master Ruby
  • Know SQL
  • Understand CSS
  • Use JavaScript
  • Learn HTML
  • Pickup HTTP
  • Use FTP
• Practice What You Know
  • Write code, scripts, and libraries
  • Start Open Source projects
  • Submit patches
• Try New Things
  • Tryout latest release
  • Find new plugins
  • Find new gems
  • Use different frameworks
  • Integrate with new services
  • Catch up on a new languages
• Write and Teach
  • Write prototypes
  • Write a gem
  • Write plugins
  • Write tutorials
  • Give presentations, brown bags, tech talks
• Assume Nothing
  • Don’t believe the hype, dogma, marketing
  • Test everything
  • Quantify assumptions
• Know Your Tools
  • Know editor shortcuts
  • Know editor code templates
  • Use editor plugins
  • Use version control
  • Use FireBug

Again, these are just a few words of advice that we can exercise to help us write better software. No one rule or axiom is enough. Other Rails developer would add additional advice, this is especially true with each new release of Rails. With each new release of Rails or Rails specific tools, we add and remove some of the advice given for a Rails developer. If I had written a list like this for a Java EE developer in 2001, that list would be out of date for a Java EE developer today. The key is that no one process, tool, framework, library, or language will make us better programmers but our daily developer routine, our behavior, and discipline…

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.

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

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.