Episode 11 : Getting Things Done

Posted at 03:19PM Jul 07, 2008 by JC Mann in Episodes  

These are Bill's techniques for getting things done.

  • Interruptions are expensive for software developers. At 2 minutes interruption is really 15 to 30 minute "context switch penalty."
  • Set expectations with your co-workers:
    • Schedule a meeting for longer interruptions.
    • Visit at or around lunch time for the shorter interruptions.
    • Have your coworkers ask if it's a good time to interrupt.
  • IM is not a 24-hour necessity.
  • Dial back the default notifications for IM and email.
  • Check email less often and set the expectations.
  • Keep a clean email inbox - "Inbox Zero" by Merlin Mann.
  • Group meetings together.
  • Use To Do lists - use whatever software you want, just keep track your tasks.
  • Check out "Time Management" by Randy Pausch, November 2007.
  • Value your time - know what your time is worth, and put your time in dollars.

Download the m4a file
File size: 9MB

Download the mp3 file
File size: 11MB

Running time: 17:38

Comments[0]

Episode 10 : Tools That We Use

Posted at 09:17AM Jun 10, 2008 by JC Mann in Episodes  

Download the m4a file
File size: 10.2MB

Download the mp3 file
File size: 12.5MB

Running time: 20:03

Comments[0]

Episode 9 : Hallway Testing

Posted at 12:55PM Jun 01, 2008 by JC Mann in Episodes  

What

  • Hallway Usability Testing was coined by Joel Spolsky.
  • JC calls it the spouse test.
  • Always test your software. Duh!
  • But, if your software has a GUI component, be sure to test it with real users.
  • This doesn't have to be a super-advanced usability lab with one-way mirrors, eye trackers, and video cameras.

How

  • Ask various people around the office to use your software.
  • Try to get people with variable levels of computer experience. Avoid
  • Give them some simple high-level tasks to perform.
  • Watch them use your software, but don't interfere. Resist the urge to help them.
  • Take detailed notes.
  • Notice where they hesitate or get confused, and ask them about it after there testing session is finished.

Download the m4a file
File size: 6.4MB

Download the mp3 file
File size: 7.7MB

Running time: 12.27

Comments[0]

Episode 8 : Runtime Improvements

Posted at 08:55PM May 26, 2008 by JC Mann in Episodes  

Techniques for improving the runtime performance of your application.

Background

  • JC worked at a company that had service level agreements (SLA) for transaction response time and system throughput.
  • Bill worked at a company that had to improve that overall speed of web applications to make the users happy
  • Both of us have experience tweaking Java server-side applications to improve performance.

Develop a Repeatable Test

  • It's important to have this test as soon as possible.
  • This test is used many times during the performance improvement process.
  • Do yourself a favor and automate it as much as possible.
  • Build into the test a "warmup" cycle. This give the application and the JVM a chance to seed it's caches.
  • Employ a mix of transactions that is most like the mix of transactions that are used in the production environment.
  • Understand that this mix of transactions represents the chemistry or ecology of your running system. Very minor changes to the transaction mix will change the chemistry of your system.
  • Make a test that stresses your system, but is realistic to use with a profiler. Profilers are wonderful tools, but unfortunately they slow down the application by an order of magnitude or more.
  • The application being tested must be in a "clean room". There should be no other applications running on the same hardware.
  • Test on the same type of hardware that is used in the production environment.

Use a Profiler

  • Don't sprinkle your code with "stopwatch code"
  • Pick a profiler that can run the application in a realistic environment.

Analyze the Database Performance

  • Measure the "round trip times" of the database calls.
  • Normalize the database metrics in a way that reveals the database calls that impact the runtime the most.
  • Compute the cumulative times for each database call type.

Only One

  • Analyze the runtime performance with a profiler, and identify the top problem.
  • Fix the top problem, and only the top problem, and rerun the test.
  • Resist the urge to fix the top three problems.
  • Only change one thing at a time, otherwise you'll never know the true affect of a specific change.

Be Patient

  • Analyzing and improving the runtime performance of large systems takes a long time.

Download the m4a file
File size: 12.4MB

Download the mp3 file
File size: 15.4MB

Running time: 24:32

Comments[2]

Episode 7 : Social Strategies

Posted at 10:40AM May 18, 2008 by JC Mann in Episodes  

It Starts With The Hiring Process

  • Even though we work in a technical field, personality assessment is an important part of the hiring process.
  • Get the interviewee loosened up by asking "Softball questions", or getting them off topic.
  • Try to simulate your work environment. For us this means joking around.
  • It's important for us to have a team with a sense of humor, because it breaks tension and relieves stress.
  • Try to have two employees interview the candidate at the same time. Preferably one senior and one junior employee.

Introduce the Elephant

  • We've used this technique for a long time...
  • ...but we didn't have a name for it until we watch the Randy Pausch's ‘Last Lecture’ video.
  • Introduce the elephant as soon as possible.
  • Sure it's awkward, but not introducing the elephant is much worse.

Download the m4a file
File size: 10.5MB

Download the mp3 file
File size: 13.2MB

Running time: 20:49

Comments[0]

Episode 6 : Writing Twice

Posted at 11:57AM May 13, 2008 by JC Mann in Episodes  

Everybody Does It

  • It's OK to write twice....
  • ...If it isn't going to impact an immediate deadline.
  • Sometimes it makes sense to create a prototype to feel-out the problem.
  • Sometimes (most of the time) the initial version of an application is developed without knowing all of the requirements.
  • Don't be the developer with "Code Ownership Issues."

Download the m4a file
File size: 9.6MB

Download the mp3 file
File size: 12MB

Running time: 19:04

Comments[1]

Episode 5 : Apache Commons Gems

Posted at 08:38AM May 06, 2008 by JC Mann in Episodes  

Apache commons is a library of several open source Java projects designed to solve many of the typical problems faced by Java developers.

General Benefits

  • You'll write less code.
  • Your code will be more readable and less repetitive.

Commons Lang

Commons Configuration

  • Handles default values
  • It does type conversions.
  • Several sources are supported, such as, properties files, XML files, INI files, JNDI, database, etc.
  • CompositeConfiguration rocks.

Commons DbUtils

Commons IO

Commons Codec

  • Normalize raw data with Base64 encoding
  • Rot13 encoding

We recommend the book Jakarta Commons Cookbook by Tim O'Brien.

Download the m4a file
File size: 12.1MB

Download the mp3 file
File size: 14.9MB

Running time: 23:44

Comments[2]

Episode 4 : Skills Every Developer Should Possess

Posted at 07:56AM Apr 28, 2008 by JC Mann in Episodes  

These are skills that are not core to what developers do, but are helpful to have. Spend the time now to learn these skills before you really need them.

Image Editing

  • Be able to make simple icon tweaks.
  • Quickly clean up images for user documentation and other presentations.
  • Know your limits, and ask a graphic designer for help.
  • Know how to splice and composite images.

Diagramming

  • Just about every developer possesses the ability to diagram.
  • Pick a diagramming tool, install it, and know it well enough so you can quickly produce simple diagrams.
  • Know how to do simple things to add some polish, such as gradient fills and drop-shadows.

Regular Expressions

Basic Networking

  • So much of software development has some kind of networking component.
  • Know the terminology.
  • It helps when communicating requirements to network administrators.

Unit Testing

Operating Systems

  • Know the OS that you develop on.
  • Know the OS that you deploy to.
  • Learn from the system administrators.

Databases

  • "Databasing", nice Bill
  • If you're not an enterprise or server-side developer, it still pays to understand databases.
  • Know what databases can do for you.
  • Try playing around with small embeddable databases like SQLite.

Download the m4a file
File size: 8.6MB

Download the mp3 file
File size: 10.9MB

Running time: 17:02

Comments[1]

Episode 3 : Unit Testing

Posted at 07:18PM Apr 19, 2008 by JC Mann in Episodes  

What It Is

  • Do we really need to describe it?
  • Ideally you should have unit tests that exercises 100% of your code.

What It Is Not

  • A load tester
  • End-to-end or integration tester.

Why

  • To reduce the number of bugs. Duh!
  • Forces developers to produce simpler more maintainable code.
  • Less code - developers don't code "neat" features because they know they'll have to test them.
  • Small methods - large "methods are impossible to unit test.
  • Better code organization - this forces the developer to be the first consumer of their code. This is a perspective that helps them see the organizational flaws in their code.
  • To prove your code works
  • Acts as a "safety net". "It's just a simple change...how could it possibly effect anything!?"
  • Further verifies that validity of your one click build and your product.

Best Practices

  • Mirrored directories structures.
  • Naming conventions: see Google's "Testing on the Toilet"
  • Don't forget to test the rainy day scenario.
  • Publish the test results to using the continuous integration server
  • tools: JUnit4 and TestNG.

Unexpected Benefits

  • It's much easier to write and run a unit test than it is write and run quick little main program.
  • Can be used to communicate progress to yourself and the team. This requires "test-driven development". Meaning that the unit test are written first!
  • It helps you code and document your assumptions.

Download the m4a file
File size: 12MB

Download the mp3 file
File size: 15MB

Running time: 23:44

Comments[0]

Episode 2 : One Click Builds

Posted at 04:29PM Apr 13, 2008 by JC Mann in Episodes  

Always be building!

What

  • Your project should have a simple build process consisting of only three steps:
    1. Get the source, hopefully from your version control system.
    2. Verify the development environment to ensure that the correct software has been install. The build process should do most of this automatically, if possible.
    3. Build - this is the "click"
  • If you have more steps in your build process, then you don't have a one-click build.

Why

  • It legitimizes your product.
  • It makes your project more accessible to other developers -- including your future self.
  • It makes it easier to bring new developers up to speed on the project.
  • It allows you more easily hand your code off to another developer.
  • It enables you to simply verify that the project is stable -- check-out to a clean directory.
  • It readies your project for continuous integration.

Continuous Integration

  • It ensures that all of the develops are aware of the changes they introduce.
  • It provides a consistent hardware platform.
  • It serves as a project archive.
  • It delivers a high-level summary to project leads and managers.
  • It readies your project for unit testing.

no build - no product

Download the m4a file
File size: 9.5MB

Download the mp3 file
File size: 12MB

Running time: 18:38

Opening and closing music: "Here I Am" by Everyday Jones - Live @ Jazzbones, Tacoma, WA, 2005. Downloaded from Pod Safe Media

Comments[0]

Episode 1 : Fresh Meat Seasoning

Posted at 04:18PM Apr 06, 2008 by JC Mann in Episodes  

How college graduates can ace the new employee interview.

Writing Skills

  • Have a well written cover letter, email, and resume with no spelling errors.
  • Good writing skills translate to good developer skills.
  • Our developers must communicate with employees across the country, and customers around the world.
  • Expect to write functional specs, design specs, and requirements.
  • Students need to improve their attention to detail. IM-style communication is not appropriate in the workplace.

Communication

  • Know your audience and adjust your communication style accordingly.
  • You must be able to communicate ideas in a clear and understandable way.
  • You'll need to explain technology to people who are not technical.
  • Getting business requirements from customers can be difficult.
  • Use metaphors to get your point across.

Humbleness

  • Developer ego is a huge obstacle to navigate around in the workplace.
  • The software development field changes too rapidly for big egos to be effective.
  • Big egos take longer to fix problems because it’s always someone else’s bug.
  • You need to be able to ask for help. Too much time is wasted by those who don’t ask for help.
  • Be open to new ideas and feedback.

Teams

  • You can’t know everything about every technology.
  • Draw on your team members’ knowledge.
  • You need your co-workers ideas to make a project successful.

Creativity

  • Share your opinions and ideas.
  • Participate in brainstorming.

Keep Learning

  • Read blogs, journals, industry news.
  • In college you “learn how to learn.”
  • You are expected to learn inside and outside of the classroom.

Get Over It

  • All the code you wrote in college was useful, but half the code you write in the workplace will be thrown away.
  • Accept that new priorities from the boss come up and projects get canceled
  • Throwing out code can be good. As changes in the software are released, you need to eliminate old code and update with new.

Download the m4a file
File size: 10.5MB

Download the mp3 file
File size: 13MB

Running time: 20:35

Comments[1]

Episode 0 : Accepting The Defaults

Posted at 06:00AM Apr 01, 2008 by JC Mann in Episodes  

Simplify

  • Avoid tweaking your desktop environment, colors, and keyboard shortcuts.
  • Simplify by going with the defaults as much as possible.
  • Software development is all about coding speed not having your screen look good.
  • Most programs have great initial key mappings, so there is no need for you to spend a significant amount of time changing them.

OK, Maybe A Few Tweaks

  • Change the text wrapping from 80 to larger. Most develop system have wide screen displays.
  • Only put in a keyboard short cut if there isn’t one already
  • Code template for localization

Custom Color Schemes Are Bad

  • It's more difficult to have another developer work with you because they are distracted by the change in colors. We won't be able to determine where a method begins.
  • It's too time consuming to change syntax elements.
  • People are used to the default preferences, don’t make them work so hard to help you.
  • If you have a laptop at home and at work, you are constantly adjusting to two different environments.
  • It's difficult to backup and restore a system with custom changes.
  • If your employer has an automated the software update process, you may find that all of your changes have been overwritten.
  • If any of your team members are color blind – and it does happen – it will be impossible for them to distinguish the colors in your code.

Embrace the defaults and minimize the tweaks, so you can spend your time on more important things.

Download the m4a file

Download the mp3 file

File size: 8MB Running time: 12:26

Comments[0]

This Is Not A Joke

Posted at 02:28AM Apr 01, 2008 by JC Mann in Episodes  

Welcome to the Versatile Programmer podcast.  I realize the unfortunate timing of our premier, but I assure you, this is not a joke.

This blog and podcast is written, recorded, and edited by Bill Kratzer and JC Mann (that's me) in an effort to share our years of experience in the Software Development and Information Technology fields.  Bill and I both have about 15 years of experience during which time we learned (a word which here means: we made the same mistakes enough times to actually help us avoid making them again) a great deal.

Our goal is to publish weekly episodes that are no more than 20 minutes in length.  If we can't communicate our ideas in less than 20 minutes, then we shouldn't be communicating our ideas.  If we fail to miss our goals, feel free to criticize us publicly.  Trust me, we can take it.  Right Bill? 

We would like to thank Versatile Systems, Inc. for making this podcast (and our paychecks) a reality.




 

Comments[1]