First Thoughts: “Coders at Work” by Peter Seibel

I’ve just started to read the book Coders At Work. The book is a nice, recent collection of interviews from many big name developers. I’ve read other developer interview books before, but this one sticks out in an unusual way: with most “interview” books, the interview is either completely boring or incredibly interesting. In Coders At Work, the interviews have varied between amazing and neutral. I haven’t gotten to a bad interview yet.

A few things jumped out at me and made me think. Jamie Zawinski’s interview made me wonder about the value of non formally-educated developers in “today’s market.” Brad Fitzpatrick’s interview reminded me of the “I’ll build everything,” but you “must know everything” attitudes. Douglas Crockford’s interview didn’t inspire me, but it did make me consider other issues within software development.

Jamie Zawinski’s interview was an amazing conversation about a guy who has many interests in learning and doing work. He is a self taught LISP developer who can occasionally get very opinionated. I found his work experience with Netscape fascinating. As a user of the early versions of Netscape, I never knew all of the politics or construction going behind the scenes. I also found it technically intriguing that the pre-3.0 mail reader within Netscape was not written in C++. I have a lot of respect for Mr. Zawinski for being able to identify a potential bias of his – he appeared very introspective when asked about hiring new developers. He understood that he could distinguish people that he could find reputable, but not those who would make good candidates.

One of the things that struck me as a bit off-putting about Mr. Zawinski was his rejection of automatic unit testing. I feel that if it was made as easy in the 90s as it is today, software would be VERY different today.

Brad Fitzpatrick’s interview left me with mixed feeling about the guy. I’m not sure if he is a guy you would want to work with, however he sounds like the kind of guy that you would want to share war stories with over drinks. He has worked on many interesting projects, mainly LiveJournal, and is one of the early “Growth Hackers {http://en.wikipedia.org/wiki/Growth_hacking}.” I like his recommendation that you should spend some time in reading other’s code. He fights the immediate urge to ignore others’ code and his approach sounds different from what I had expected: I expected his approach to making suggestions on other people’s code would be antagonistic. However, it was described as the following:

  1. Code copies are distributed to the audience – in digital and paper form

  2. The developer presents their code line by line

  3. Q&A time

  4. Suggestions / feedback from the audience

This struck me as different from my experience where code reviews tend to be either technically or personally antagonistic (or both). This approach was more similar to proofreading a paper you just made or audience-testing a book you just wrote.

The two things that really put me off about Mr. Fitzpatrick was one of the questions he asks in interviews, and the other is the insistence of knowing everything. Mr. Fitzpatrick’s “famous” interview/programming question was a recycled question from his “AP CS” exam. The question is to write a class that handles large number arithmetic (rewrite BigDecimal). It appears that he uses his previous experience as a baseline for evaluation. I also got the feeling that it is a way for him to “show superiority over others” (over something he did many years ago a high school student). Second, he is incredibly insistent over knowing everything about how every layer works. He ranted against high-level language developers because they didn’t know that a specific way of polling may not work on a specific deployment machine. He even ranted over those who deployed towards a VM because the VM’s “virtual”->native OS/hardware has been abstracted. I feel that in 98% of the cases he’s picking up pennies in front of a steam roller.

I was not very thrilled with Douglas Crockford’s interview. Primarily because it dealt with Javascript, it was a little too high-level for my taste. During the reading of this interview, my mind went back to Mr. Fitzpatrick’s interview. It made me wonder and realize about how you find the “best” tools. I find it incredibly difficult to keep afloat of all the languages and tools available. Recently, for example, I just learned how – and why – Git, Jenkins (plus the automated unit/lint/reporting/checkstyle plug-ins), and deep Maven knowledge are really good things to know if you’re developing in Java.

When new languages, tools, and frameworks come around, I love to read about them and learn how they work (if they’re useful and interesting enough). However, time is limited: how do you identify the tools that would solve the most pressing need you have?  Prior to Jenkins, I built everything via an IDE. Why would I need an automated build tool? I’m the only developer on the project. Prior to Git, I used Subversion – it did everything I needed. Why would I want to make “sub-commits”? Prior to Maven, why would I want to have the build tool automatically deploy the WAR file or require that all unit tests pass before generating an executable? (I’m running unit tests all the time anyway.)

Later it made me think about the code reading suggestion and I realized: I’m not very happy with the code review tools I know about. ReviewBoard looks nice, but that is for only for Ruby. Should I write my own? Where are the existing tools for Java (which can also integrate with Maven and Jenkins)? Are the tools good? Are there others out there that have solved this issue? Is it worth setting up a code review tool just for this? This are questions I’m not sure how to answer.

Overall, I really enjoyed that this book goes over many topics – personal projects, interview questions, and famous debugging stories. I do occasionally enjoy a story bragging how the developer’s language or tool was miles ahead. However after reading about their accomplishments in a serial fashion, it just gets old. Perhaps interspersing their accounts in a more conversational form would have made this book more interesting, and easier to recommend.

Similarities of the individuals who were interviewed:

  1. All have a strong focus on one particular project

  2. Each interviewee has worked in many companies

  3. None of them focused on the reputation of the company they have worked for

  4. All have interesting debugging stories

A cool new Argumented Reality Application

It’s just been reported that VW is working on an Augmented Reality (AR) application that will assist in the repair of their new vehicle. Although AR is not a new technology its still “cool” and an interesting technology with a lot of potential.

The only concern that I have about the VW application is localization of the device to determine precisely what the application needs to highlight. If the localization is not extremely accurate and up to date, it may highlight piping for air/liquid as an electrical line. That could cause major problems, if the user repairing the vehicle isn’t able to distinguish between the two.

Who would benefit from a TrueCrypt API?

On my drive back from the client to my hotel, I was thinking. Wouldn’t it be cool if Seafile could synchronize to encrypted containers? From there I started thinking about what would be required to pull this off. Firstly, you would have to extend Seafile to support an attribute that lets Seafile know if the storage location was available or not, and then you would have to have something that could manage the encrypted container.

This led me to another idea: giving TrueCrypt an API. At the moment, version 7.1A, it does not provide an API to do so. However, it does provide an interface (GUI for Windows, and CLI+GUI for Linux) and a system level driver. If we were able to extend TrueCrypt to accept commands via an API just consider the possibilities:

  1. Other applications would be able to securely store your files
  2. Seafilecould download and synchronize to a secure location
  3. Shell extensions could be written for file managers to package folders into TrueCrypt encrypted files.

Ok, that isn’t as impressive of a list as I thought it would be. However, I am confident that there are more use cases out there.

There is a current attempt to do just this. It is by nightnic, however it only targets the Windows platform. One of the bigger hindrances of making your own API for TrueCrypt is that the source isn’t very extendable. For a user to include the API custom support, he or she would have to compile the source and patch in the API source. Additionally, from the looks of it TrueCrypt has a legal document in front of the source that may scare away those who wish to extend TrueCrypt.

The Problem with Resolutions

I guess you could technically claim that I didn’t fail at the resolutions I made earlier this year. The year isn’t over, however I believe that having long term goals such as these may be a bad idea. At this point, I believe that many of the resolutions I made [I.e. Learning R, meeting people who dealt with airline systems, and learning GridGain] may not be the best use of my time.

It might be a better use of my time to do periodical reviews of my current skillsets and recent tasks rather than to push forward blindly.

I’m not giving up on learning new things. I’m just not going to limit myself to a list.

Some of the technologies/tools I’ve been learning lately:

  1. OpenStack
  2. ArchLinux

Some technologies I would like to learn:

  1. Storm
  2. Ansible

My Two Cents on Interviewing Software Engineers

In the technology industry, interviewing someone is a tough process. It is a very complex problem that attempts to solve a collection of goals into a [best case] mutually satisfactory outcome. The interviewer needs a person who will fit in the working environment, perform tasks that are expected, has the needed skills, and is competent to do that job, all while avoiding an undesirable hire. The interviewee is looking for a new position in a reasonable environment, with people they can trust, and that helps them obtain the lifestyle/financial goals that they wish to achieve. There are three outcomes of this process: hire, wait for more experience, or don’t hire. Dancing around the decision, or making this process more difficult helps neither party.

What I’ve found incredibly frustrating is the attitude of many of the interviewers that I have been interviewed by. Most of the individuals whom I have been interviewed by have been highly combative. They want you to prove that you know what they want you to know, whilst simultaneously proving that you would be a good cultural fit. For example, smaller organizations will throw out Google/Microsoft like interview questions just for appearances. Is this necessary for determining the quality of the applicant? I don’t believe that it is. Unless your industry requires every engineer to make close estimations, it appears to me that it is more of a way to build an unrealistic ‘tough-guy’ image. There is absolutely no reason for an interviewer to be combative with an interviewee. The goal, on the company’s side, is to find out if the applicant would provide value for the company. If an individual’s average day is fairly easy going, why make the interview stressful? It’s akin to demanding an auditioning actor to recite the entirety of Shakespeare’s work when interviewing for a non-speaking role in a 30 second commercial.

Another issue that I’ve found is the amount of criticism of interview code. I’ve had a range of this: “code portfolios,” sample programs prior to the interview, temporary assignments, IQ tests, talk and coding, and white board exercises. Only a few of these coding practices are reasonable, the others are unrealistic and stressful. The IQ/aptitude test was a part of the application process at IBM. It was a little silly, and timed, but I guess I was within their upper and/or lower limits for acceptance. The test was online and it was after the interview, so it wasn’t so stressful. I’ve had an organization request a coding portfolio; that is a horrible idea. Portfolios are required of those who do visual work, but code portfolios suffer from a lack of context, industry acceptance, and lack of time to compare and contrast multiple candidates’ submissions. I’ve had to work with one group temporarily [after the interview] as a trial period. This wasn’t so bad for a few reasons, one the company paid for my travel to get me there (going from the US to Europe), was only for a short time and lastly, it isn’t unreasonable to ask for this when considering very long distance applications. However, the downside to this is that it negatively impacts the discreteness of interviewing a new workplace.

I tend to like coding samples prior to the interview. If you’re given a problem set to choose from, it gives the interviewee a chance to emulate the conditions in which they would be working in. The interviewee is able to ponder, on his/her own schedule, about the problem, design, code, test, and package the code. I am not a fan of coding on a whiteboard. It is a completely different experience from how one codes. It strips away the tools and contexts, and expects the individual to perform their tasks in a completely foreign way. If the interviewer was asking for high level details, this request isn’t too far fetched. From my experience, there are a lot of organizations that attempt to have the interviewer watch an interviewee code via a live collaborative editor while on the phone. These are some of the worst interviews I’ve ever had. The task is not humanly possible. The tasks are usually set up in a professor/student manner. The process is usually: a problem is presented, thinking occurs, have the interviewee talk through a problem, code while explaining the code, and to use a foreign editor at the same time. To make things worse, this is all done while the interviewee is holding a phone and typing on a keyboard. It is not humanly possible for an individual to communicate, and solve deep problems at the same time, to make things worse you’re being judged at the same time.

Lastly, I have been asked to code up a problem or two, with the interviewer on a computer. This has been done in a peer-wise and non-peer-wise fashion. Usually this involves a small problem, and you’re given a new project in an IDE. At times, this may be a little tough if the IDE is unfamiliar, but this at least attempts to reproduce the working environment.

What are some of the questions that I would like to be asked?

I believe that an interview should be more for an inquisitive time between an interviewer and interviewee. There is no benefit from trying to make a stressful interview even more stressful via combative techniques. So I think there are a few questions that would make it easier:

  1. Ask questions related to the projects that the interviewee has worked on before. [Preferably a non-work based project]
  2. Ask about some of the challenges faced on the projects. For example, if the project required a high level of performance, how did they solve the communication issues between components? If the project dealt with numbers or precision or money, ask how they solved the issues with floating point math.
  3. Ask what an individual project taught the interviewee.
  4. Ask about times where the interviewee has conflict with another coworker; ask how he or she would have resolved the issue. (Don’t ask for opinions or gossip surrounding the conflict)
  5. Ask about what blogs/technical content they follow.

These questions get the interviewee to talk more about what they should be confident on talking about. The questions also demonstrate the ability to work with others, willingness to adapt, interests, technical strong points, experience, passion, and potential weak points. Lastly, to the interviewer, consider the individual that you are communicating, with being hostile won’t do you any favors if you have to work with them later.

PSA: Software Development Tip: Clean out your Code Base

There is a diplomatic mindset that many developers have: It’s better to orphan code, than it is to delete it. This, although less destructive in the short term, can become very destructive in the long run. Leaving orphaned code may:

  • Encourage Reuse later on
  • Dramatically increase build times
  • Increase the amount of time needed to perform version control [A bigger code base takes longer to examine]
  • Reduces one’s ability to navigate through the code.
  • Increase the executable size
  • Increase maintenance times

So in short: If the code is no longer needed and used, remove the dead code. If you’re using source control properly, the change can be reverted.

If the team you are working with still insists on orphaning code, at least have them to agree on periodic spring cleaning of the project.


 

Good News to those who use Maven and are working on J2EE web projects in IntelliJ: Here’s a guide.

 

A Skill that All Technical People Can Use (System administrators, Database Administrators, Developers, etc)

Top-notch communication skills are vital when communicating detailed technical topics. Poor communication skills are seen as a lack of interest, understanding, or motivation. I realize that perception isn’t always true, but making the correct impression on others is extremely important.

I’ve seen many of these “sins” from technical presentations in graduate school and within local technical group meetings. I’ve even run into some of these issues personally. A very good video about what I’m talking about his “Package Management and Creation in Gentoo Linux.” I realize that it’s easier to criticize than to present, however after you are aware of some of the issues below the presentation is becoming aggravating.  Donnie Berkholz, if you are reading this, I am not criticizing you personally.

  1. Rambling
  2. Use of “umm” and other fillers
  3. Poor posture
  4. Bad lighting
  5. Having a monotone voice (This isn’t a huge issue in the video)
  6. Mumbling
  7. Failure to list assumptions (What skills should your audience have)
  8. Failure to explain why the content you’re presenting is valuable to the audience
  9. Unorganized slides
  10. Lack of overall summary of the presentation at the beginning
  11. Lack of prior practice
  12. Lack of mentioning of where to find the slides online
  13. Going off topic within the presentation
  14. Lack of confidence in material
  15. Overloading the slide with lots of unneeded details
  16. Fanboyism (I’ve seen it in a few of my fellow students’ presentations in graduate school)
  17. Not tabling questions that go off topic (Not shown in the video)
  18. Low quality graphics (Not an issue in the video)
  19. Speaking too quickly (Not an issue in the video)

How would someone Improve Their Presentation Skills?

It’s not possible for a presenter to be able to find their own issues. Presenting is one of those things that requires feedback from others.

  1. Take a class on public speaking at their local university, technical school, or even library. Local toastmaster organizations can help with this, too.
  2. Test your audience before and after the material. The higher post-presentation score the more they learned. For this to be a good measure, it requires 2 tests with similar material. For example, if Mr. Berkholz was to apply this: he would ask about keywords, behavior etc in a multiple choice form. This will not address issues with social cues, but it will give an overall indication on how effective the presentation was.
  3. Give out a general survey that must be filled out at the end. This works well for a large conference with lots of speakers. Ask questions such as “The speaker appears to be an authority on the subject [Strongly disagree, disagree, neutral, agree, to strongly agree]” or “The subject material is interesting …”
  4. Ask for someone’s opinion that is outside the industry the content fits into. For example in Donnie’s case, ask a psychologist to be your practice audience member.
  5. Involve audience participation throughout the entire presentation. I love this piece of advice. It turns a simple, and short, presentation into a full-length lecture. Also, it helps to understand the audience’s interest.
  6. Practice your presentation beforehand – a lot.
  7. Review your slides before hand and prepare secondary screens. Fumbling around with unnecessary external programs during the presentation irritates your audience.

A Few Signs That Your Project May Be In Some Serious Trouble

  1. Lack of leadership in developer operations
  2. A lack of reporting of improvements in code reuse, coverage, test cases, and stability.
  3. Underutilization of frameworks and libraries used within the project.
  4. Lack of disposable runtime environments [for development and testing].
  5. Build times are unknown.
  6. Long and detailed documentation is required to build your product.
  7. Dead code is left in the code base to rot for years.
  8. Bugs are being reproduced as unit tests.
  9. Third Party dependencies are not being upgraded.
  10. Code is badly organized. Models are placed anywhere, packages aren’t organized, etc.

Make Mobile Phone Unlocking Legal Again

Recently, an exemption from the DMCA that allows for mobile phone unlocking was removed. Now anyone who unlocks a mobile phone is participating in an “illegal act.” That’s right, a device that you may have paid for, or have over paid [if you’ve had the phone long enough, and bought it under a carrier subsidy] has legal protections to prevent the owner from messing about with it. Given this reversal, the government is assisting in the creation of a monopoly that only benefits the mobile phone carriers.

What can you do as a US citizen? Well not much really, but there is a direct petition to Obama. Let the president know that you ask for the freedoms that are granted by many, other nations in the world.

The petition is currently at signature 64k out of 100k needed.

Features I’d like to see Added in Wikis

For the last decade, wikis have not changed very much. Even minor features such as AJAX support are still uncommon items. The following is a list of features I’d like to see added. A few of these items are available as plugins, however I am referring to having these features baked into the actual product.

Live Collaborative Editing

If you use Google Documents with others you will notice this: live collaborative editing. Usually the first time that someone notices this it either freaks him out, or just blows his mind. Multiple users can edit the same document at the same time, whilst receiving the changes in real-time. Having this support on a wiki would make the page lock / change conflict problem go away.

Importing Data Framework

It would be immensely helpful to have some sort of feature within a wiki to import data from other sources: images, RSS feeds, CSV feeds, etc. With a uniform way of bringing-in data, plugins could become a bit more generic and support the transformation. For example: let’s say that you have a build system, and it produces a build log file. Wouldn’t it be helpful for having that file be placed on the wiki [within a certain section] where it could be commented on? With a data framework, there could even be a plugin that could grep the output and only show the important sections.

Graphing Support

Charts are important for simple visualizations of data. Why this requires selecting and learning how to use a new plugin is beyond me.

Drawing

Wikis seem to be text based only. I have only found a small handful of plugins that support the editing of pictures. Even fewer use SVG. I’d like to see the ability to edit an SVG picture built into the wiki software.

OpenID

Why wiki software continues to roll their own authentication system by default is beyond me. This item seems like a no brainer. Create an OpenID authentication mechanism that uses the top providers [Yahoo, Google, Facebook]. If need be, revert to a local authentication method if there is a lack of internet access – or if the wiki is being deployed exclusively internally.

APIs for Dealing with Content On The Wiki

Lastly but not the least important, create and promote a uniform wiki API. This would allow for other systems to automatically push content onto the wiki, or pull it. This would be great for a monitoring system to:

  • create a new page on the wiki
  • post configuration details and current state
  • maybe even show statistics

Also with the API, the same monitoring system could grab a wiki page and check for changes in the configuration details. Granted, there are potential issues with the configuration details changing on a wiki, however at the moment this is more of an idea rather than a real world implementation.

Another example: WordPress could use wiki support to have multiple editors collaborate over a post within a wiki Page. WordPress could also, with an API, pull the wiki page to make it a blog post.