Juixe Techknow

Here is a snippet of a conversation I had on Twitter about code. I thought it was interesting how my conclusion lead to a belief that all code is inherently evil. Maybe I went flew off the rails on that conclusion, but if early optimization is the root of all evil… how evil is regular code?

• @techknow: Less code is the best code.
• @Archimage: So you are saying that no-code is the best code ;-) (yes I know what you meant).
• @techknow: The inverse of this means that any code is bad code. Sort of like Original Sin of Code!?
• @Archimage: Which implies it can be made better.
• @techknow: Only if it repents.

In the following snippet of conversation, @newparadigm introduced me to Let Me Google That for You (lmgtfy.com). This site animates someone typing a search term into a page that looks like Google and hitting the search button. If anyone ever asks you what the private keyword is for, just direct them to Let Me Google That for You!

• @techknow: There might not be any stupid questions, but it is a lot smarter to find out the answer yourself!
• @newparadigm: AGREED – http://tinyurl.com/ppe44x (lmgtfy.com)
• @techknow: LOL that’s kewl! If anyone ever asks me a simple question question I am going to send a link to Let Me Google That for You (lmgtfy.com).
• @newparadigm: haha. my boss only had to send that to me once before i stopped asking questions before my own research!
• @techknow: If this only worked with or internal wiki, it would make me 20% more productive.

If you like to chime in with our thoughts about code, process, management, and just about anything else, hit me up at techknow and juixe on Twitter.

Large conferences such as JavaOne or Wordwide Developer Conference can cost over $1,000, just for the pass alone. When you add air fair and hotel accommodations this can easily reach over $2,500! This is all well and fine if your company is going to reimburse you. But during these tough times companies are making all sorts of cuts.

There are plenty of regional conferences such as MountainWest RubyConf and Gold Gate Ruby Conference and conferences tours such as No Fluff, Just Stuff and Future of Web Apps that are more reasonably priced. But even at $99, there are cheaper alternative options!

Find the local user group for the technologies that you are interested. User groups typically meet up once a month to discuss latest trends and demo recent products. No matter where you live, there is probably a Java or Python user group. If there isn’t one start one up and coordinate using blogs, forums, meetup, and Twitter.

In addition to user groups, I’ve attended to barcamps and unconferences. There are all sort of regional barcamps organized around all a variety of topics. When the iPhone first came out, I attended a barcamp in the Adobe office in San Francisco were geeks got together to experiment, collaborate, and program.

If you live close to a university, the Computer Science department might offer a colloquium series where they bring on different speakers, from entrepreneurs to visiting professors.

In addition to user group meet ups, barcamps, and academic presentations, there are tons of video presentations from top quality presentations online. Many of the presentation put on by Google are posted on YouTube under Google Tech Talks. You can find some of the RailsConf 2009 presentations on Blip. Confreaks has a slew of videos from all sorts of Ruby conferences such as Goruco and MountainWest RubyConf. If you want to catchup with the content of from a recent conference, but for whatever reason you are not able to attend, don’t feel left out. Most presenters put up their slides of their presentations, and many conference organizer put up video of the presentations.

These are just a few ways that you can keep up with the developments your field.

There is an interesting rant over on Coding Context on how Joel Spolsky and Jeff Atwood are brilliant assholes because they are organizing Stackoverflow Dev Days. It may be true that Joel and Jeff are self obsessed ass wipes, but I am note sure it is because they are trying to cash in from the inadequacies and inferiority complex of other developers.

Micah, the guy behind Coding context, brought up the point that the guys behind the Stackoverflow Dev Days conference are exploiting their developer community to build their personal brand. According to Micah’s calculation, the series of six conferences can net nearly $200,000 and as of yet they don’t even have the presentations or speakers lined up!

Personally, I am put off by their floating point error size ego, dismissive attitude, and general writing style while a loyal following finds them eloquent. That said, Micah is totally right, they are building their brand! There two respective blogs attracts a large portion of developer eyeballs. Their joint venture, a question and answer site for developers, gets millions of hits monthly. In addition to this, Joel Spolsky runs a job board which he claims has made him over a million dollars. But is this all bad? Is this devexplotation?

In regards to their tech days, they are not the first to realize that there is good money in running a conference, look at Future of Web Apps, No Fluff/Just Stuff, and all the Web 2.0 O’Reilly conferences. A few years ago, I was part of the executive committee that put on a one day conference for a non-profit. With just corporate sponsorship alone, in a good year, we would net $35,000-$50,000 cold hard cash without even trying!!! And remember, in addition to money for ad space, conference organizers are able to get companies pay for printing material, goodie bags, giveaways, and even lunch. To a good organizer, everything including the Wi-Fi identification and mailing lists, can be had for the right sponsorship level.

From a conference like this, I would be concerned by the quality of speakers. What I feel happens, specially when there is corporate sponsorship, is that the sponsors will use the presentations to pitch their tools and try to up sell the audience to their proprietary tools and services. No matter what they say, Conferences like this are used as promotional tool, and they will sell out to sponsors to use their allotted time and space to pitch to a captive audience. Similar remarks have been said of JavaOne. One complain that I have heard of is that JavaOne is to Sun centric, even though they are the ones that put it together. There is a fine balance between corporate sponsorship and speakers so that the conference does not seem like one long infomercial. It always helps if there are different tracks!

In Slashdot style, here is the formula for a business model for running a conference!

• Schedule a conference
• Ask for volunteers in exchange for badges and shirts
• Sellout presentations to sponsors
• Give out sponsors’ marketing material in goodie bags
• Have sponsors buy lunch and provide wi-fi
• Charge per seat
• Sell books, shirts, and anything else
• ?????
• Profit!!!

This is not all to different from the open source business model which includes building a community, charging for training, selling books, licensing technology, providing certification, and putting on a conference …. and profit!!!

At a fundamental core, Google News and RSS tried to answer the same problem, how to aggregate the most current articles from your favorite news sites and blogs? Having a ton of raw brainiacs with twenty percent time Google over engineered their solution with more artificial intelligence than common sense. Google News came out of an engineer’s 20 percent time and allowed him to simultaneously read top head headlines from thousands of newspapers.

Another approach to this problem, having to visit multiple sites to catch up with the news, was Really Simple Syndication (RSS). RSS has grown to be used in news aggregators not too unfamiliar to Google News, podcasts, and many other websites and programs. One example of a online RSS aggrigator is Happy Coder’s Daily Digest. Happy Coder’s Daily Digest aggregates the latest headlines from nearly 100 of my favorite technology bloggers.

In my mind, RSS provides a lot more value, even though it’s history is marred with constant battles over standardization. Those battles are what forged RSS to a de facto technology and it allowed for uses not envisioned by its original creators.

One of my pet tech peeves is repetition and redundancy. I wish documentation had the same level of reuse as code. But in reality I find that we tend to repeat ourselves even in code just for duplication’s sake and we don’ realize it. Were I see a lot of superfluous repetition that is easy to overlook is in naming of variable, fields, columns, and classes. Here are a few examples of what I mean.

You have a folder called ‘Experience’ and under that all files are named like the following ‘exp_search_test.xml’ filename. The filename repeats that this document is an experience, whatever that really means. If you really want to indicate a file is of a given data type use the extension, so you rename the file as ‘search_test.exp’ or ‘search_test.exp_xml’ to indicate the file type.

Another example dealing with code is that variable names repeat their purpose. For example, you have an Employee class and the class has a subsequent employeeFirstName. If the variable is inside the Employee class, it is not required to prefix the class name to each field name. Use the context of the class to define meaning, don’t ad verbose comments to repeat what is clearly obvious like ‘This is the employee first name.’

I see this same problem in database column names. Another example that comes to mind of a real database schema used in production is of a fund table with column names such as fund_long_name, fund_type, etc. Again, I prefer concise and succinct column names.

Let me repeat myself again, if you try to add context to field name where it is already obvious you actually populate the namespace. Here is a more concrete example of that, again from code used in production. There was an ExcelExport class that contained the following two methods, exportExcel() and urlExportExcel(URL). Which method name should we refactor to simplify the API? … You might be thinking to rename urlExportExcel(URL) to simply exportExcel(URL) and in this way provide a concise API by overriding the same name but with different parameter list. Remember, the method signature of most languages includes the parameter type/list. But I would not stop there, I would actually rename the exportExcel() and exportExcel(URL) method names to simply export() and export(URL)! Why? Well, because you don’t just export data to Excel, you usually export data in different formats and flavors such as XML, RSS, CSV, etc. I hope that you can now see, that simply naming this method as export and using polymorphism, interfaces, subclasses, and factory pattern you simplify not just your method names but code.

An example of recursive repetition is where a word in the dictionary refers a different word, but if you look up the second word it refers to the first. As rule of thumb to avoid dubious verbose recursive repetition, variable names are not comments and comments should not repeat variable declarations.

I’ve worked in a variety of projects, in a myriad of languages, and have learned the following universal truths about software development the hard way.

• Commented out code are not comments – Use version control, don’t track code changes by commenting them out. Commented out code is schizophrenic code.
• Let your reputation and code precede you – If you work on open source projects, blog, and work your network, you will get more job offers even when you aren’t looking for a job than people that are looking for a job and just email out resumes.
• Don’t make excuses for code, let it speak for itself – You are paid to find solutions using code, not find excuses for your code. ‘It worked on my machine’ is not a solution. You will not ship out your computer to the client with the application.
• Don’t take code personal – Don’t take code reviews personally, it is not about you but a business feature and the overall performance of the application.
• Your code is your career legacy – For years after you leave, those that will maintain your code will either curse you or thank you.
• Coding does not equal programming – Writing code is not the same thing as software development, one requires thought while the other does not. Just like playing with your iPod does not make you a musician.
• Code is about learning – Moore’s Law states that technology doubles every 18 months, you should keep up. If you are not learning you are doing it wrong. Every project is an opportunity to learn.
• Code is communication – People will read the code you write. Use best practices and common design patterns and idioms. Strive for simplicity over impressing the monkey on your back. Your code should communicate clearly and concisely it’s intent. Code talks, bugs walks!
• It is not the tools that make a developer – Know your tools and use them to their full power but don’t use them as a crutch! Switching between IDEs should not stop you on your tracks because you can’t find the correct code generation wizard. Michelangelo was a great artist with nothing more than a chisel and a slab of marble.
• Don’t trust your code – Trust in your coding abilities does not replace repeatable testing. Don’t trust your code, assumptions, or users.
• Code is not written in Latin – Code is not dead once the application ships. Code is always refactored, modified, re-used, and evolving. Your greatest strength is not writing mountains of new lines of code but maintaining, refactoring, and herding existing code into performing business requirements as per an agreed specification.
• Respect the API – Your API is a contract others will depend on. Keep the API clean and explicit! The least amount of methods you expose is less testing and maintenance and documentation that you need to maintain.
• Code outlives its intention – As much as you would like, writing your application from scratch in the latest programming language or framework will not benefit the number of end users that for one reason or another are stuck with the current version of the software. Code can outlive it’s original intention, design for extensibility and adaptability.
• Code means different things to different people – In the end, to end users code simply means the ability to do what they expect.