A suggestion for those who create projects for open source

Please include a tutorial on how to use your product.

An example of this:

I saw a talk on FiloDB. It sounds like an interesting time series collection database. The technical challenges sound interesting and the architecture sounds like its sensible. However, when going to the project, there’s nothing there that will get me off the ground and working with it quickly.

TL;DR Write documentation in a manner which it helps to lead the user to use your product/project successfully.

In Support of Complex Software

We have some major communication and usability issues with software. I’m not referring to the lack of documentation (although quality documentation is needed), nor am I talking about UX. It appears that there are way too many choices in what software product to use, but there is very little structure into how to implement it to solve your problem. For example, there has been a bit of a fight between Swarm, Kubernetes, and Mesos. Even though they have similar usages, each of them have vague descriptions of what they actually do. When I’ve seen comparisons of the products, I tend to see complex routing strategies being discussed rather than what they have in common – or where one product succeeds over others (and fails in other ways).

What am I ranting about? Well, a lot of products describe what they do, but the descriptions rarely ever make it easy to understand to the reader. All of the projects that I talked about earlier describe what they do [they tend to make sharing physical resources transparent for containers, each have their strengths and weaknesses]. All of the projects claim that they help to build a cluster, but each tend to fail on describing how they do so on an infrastructure level which can actually give implementers a shot at making an intelligent decision for their environment/purposes. They tend to build up a picture in the user’s head, only to be let down, that it’ll make the user’s scaling problems go away. Unless the user of the project has made their application distributed (in the way they expect), these technology choices won’t help them.

Silicon Valley has latched onto a harmful mindset. This has been encouraged via the Lean Startup/MVP mentality where someone decides what they believe that you need and only that is what is built. Your actual needs from the product are dictated by someone else, and are only implemented when they decide it’s going in the product. Complex products tend to be sidestepped due to insecurity about the people using it. It makes me think that technology being produced by startups in the Valley are akin to promoting the education of math to its users, but to be in denial of operations beyond addition and subtraction. Complex products can work, and can be used to their fullest extent. The problem is due to the communication about the product. Rarely have I ever seen a complex product described in a simple-enough manner up front to make it easier for the user to explore different avenues after he/she has achieved proficiency in the basics.


Some of the Best and Worse Things of Hotels

My job requires that I travel quite a bit, and stay in hotels. I’ve also travel a bit for vacations. So far here is a list of things I look for in hotels:

  1. Having to prepay for a room is very irritating. It is even more irritating if the hotel is in a foreign country. This can cause issues with bad service or offerings that weren’t up to how it was described. Authorizing a credit card to an extremely high amount is also rather nutty. If the individual is not aware, this can cause legitimate charges to be rejected.
  2. When travelling for vacations, I tend to like apartment type rentals. They tend to be cheaper per the week, and often don’t include daily maid service.
  3. Comfortable beds are a requirement. I haven’t had issues with this in the Fairfield Inn, or the Hilton properties.  However, I have had issues with this in an Aloft and Town Suites hotel. I tried to talk with the property managers. In each case, I was told that the hotel had only one style of mattress: extremely hard. This is irritating because it makes sleeping uncomfortable and difficult.
  4. A good breakfast: I’m not expecting a made to order breakfast. However, if the scrambled eggs are overcooked and dry or if the meat product is questionable, this is extremely irritating. When I stay in a hotel, I often have no other choice than to stay in one. If I’m at home, I’ll cook the meal myself.  Having a bad breakfast service reminds me that I rather be at home. Also, if you charge for the breakfast, it better be good.
  5. If the room has a kitchenette, please stock it with the items one may need to cook with. A good example of this has been the Inn Sight apartments in Berlin. They include the spatulas, knives, glasses, utensils, and multiple pots + pans.
  6. Able to make taxi requests very quickly. When late for a flight leaving Berlin a year ago, I found that the Mercure was able to do this from their computer. Within 3 minutes of walking out the door of the hotel after checking out, the taxi was there.
  7. Easy to work with the TV: I rarely ever watch the TV channels that are provided with the room. I tend to load my tablet up with TV shows and watch content from my tablet onto the TV. If a hotel makes this difficult by either disabling the input selector or making the HDMI ports difficult to get to, this is irritating.
  8. The room design: This isn’t hugely important, however it is rather nice to stay in a modern-European styled hotel room.

Why your PodCast May Irritate It’s Listeners

Radio programs have evolved over time. Their broadcasts have transformed from a strict, informative purpose into many different formats. However, one of the main changes of the radio programs has been a wide reach of an audience and more listener-friendly formats/mediums.

In contrast, podcasts are rather slow to catch up. Podcasts suffer from amateur-dominated issues. I listen to quite a few Podcasts while I’m working, driving, or in my spare time.

A few issues that I have with the podcast technologies have been:

  1. Tools for synchronization/downloading, there is no standard way to grab and listen to podcasts. I’m looking for a tool that is similar to the old Google Reader.
  2. I would love to have a replication system that would put the podcast on my phone/wifi-connected mp3 player/etc.

Those two issues aside, there have been other problems that I’ve found with many podcasts:

  1. Production quality is less than stellar: When the audience member listens to the episode, they have to imagine what the broadcasters are describing. The Java Posse conferences is a good example – there are a lot of non-audio actions occurring and it becomes distracting. Other problems are related to background noises (cars, animals, talking in the background,etc). If the broadcasters wish to improve their quality: get better quality mics/filters, storyboard/plan out the show, and cut irrelevant sections of the recording.
  2. Rambling: This becomes irritating as it is more difficult to skip over unrelated tangents. I’m not suggesting that all non-topic communication should be avoided, but there are sometimes where the rambling is endless. I see this issue in the Java Posse podcasts when there are arguments on topics such as patents, DRM, or other topics that would be better left on Slashdot, Hacker News, or Reddit.
  3. Uncomfortable conversations: I have been turned off to the Programming Throwdown. Often times the conversations don’t flow, or it feels like the speakers are fishing for conversation.  Systm, with Kevin Rose, (if I recall correctly) use to start out with the two presenters having a conversation over a beer. There have been many episodes with the Java Posse that have been conversations over a glass of wine or beer. These episodes feel more informal and easier to listen to.
  4. Teaching rather than conversing: With Programming Throwdown, I get the sense that they are trying to teach something, where the listener would be better suited for learning by example and resources. To learn something from this show, it requires quite a bit of attention, and comprehension. If you’re going to teach something, do it in a way to trick the audience into learning about it explain why a technology is so amazing and then go into the details, rather than trying to inform and then engaging the listener.
  5. Not putting breaks or introductions: The podcasts Man Show (by Caleb Bacon) and the Art Of Charm (a dating podcast) do a very good job at this. Man Show has a quick introduction, which is one of the most interesting statements of the show. Both of the shows also put in breaks. Like advertisements on the radio and TV, this allows for the listeners to pause and contemplate what was said.
  6. Not producing show notes: I don’t have a direct example of individual podcasts that don’t do this, however having show notes helps the listener to research topics mentioned in the podcast, and to find podcasts via searching topics.
  7. Tone, interest, and presentation: Podcasts as a medium are all about telling a story or convincing someone to consider ideas. This American Life by Ira Glass captures the listener’s interest via the delivery of the content. There are a few episodes of the Hacker Podcast that are less than stellar. It irritates me quite a bit when a speaker doesn’t have interest in what they’re saying – it wastes everyone’s time. I would be more tolerant of this issue if the medium was a live broadcast, however it’s not.
  8. Video podcasts: This is a personal peeve of mine. I don’t like to be restricted to a video-cast. Audio allows for me to listen to them while work. Video has to compete with my focused attention, and with other videos on youtube and/or television production-quality programs. That being said, I do enjoy a lot of the InfoQA presentations, only when I get the time to watch them.
  9. Length: Each episode should be long enough to get into detail on the topic, but short enough to avoid overwhelming the listener. My friend Warren calls this “terse verbosity”.
  10. File names should reflect the topic of the episode, and the Podcast name: When you’re dealing with names like “hpr3234.mp3”, it becomes difficult to pick the podcast you want to hear. Man School does a great job with this by naming their files: MS-<Interviewee>.mp3.
  11. Metadata: Fill it in. If you have a decent stereo in your car, and it plays MP3s from storage, then it is very helpful to pick out the podcast by its metadata. I can understand that it’s a little irritating to put in the data after making the show and editing it. But it’s one of the little things that make listening to the podcast just a little easier.

I find Podcasts incredibly useful, if not more so than most magazines. They’re free, they can go into depth on interesting topics, they tend to be focused on the interviewee, and lastly they’re convenient.

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.

3 Strikes Budget Rental Car: You’re Out!

I’ve been a loyal renter of cars from Budget rental car. They don’t’ have a particular set level of status, or give points, I don’t mind, I like things to stay simple. In some periods I’ve had to rent a car for work every week for 4 months. [That was my longest renting streak with Budget]. However there have been 3 major issues that I’ve had with Budget:

1. Need to change your contract during the time you have the car? Call up Budget and you’ll be sent to sales. This is a new sales avenue for them. They will make an adjustment to the contract at a new rate and charge a fee to do this [if you prepaid].
2. Have a misconnect or a schedule change with a flight? Despite that they work alongside the airlines, they do not acknowledge that misconnects and huge delays do happen.
3. Mysterious dings/scratches. I returned my car in ATL last Thursday evening. A ding was found on a wheel well. [How this got there is beyond me and there was no indication of neighboring marks that would give more hints to this] The issue here is that no inspection was done after receiving the car. They agents refused to inspect the car and demanded that I sign the damage form blank. How this will be billed/handled by insurance or credit card is beyond me.

More information on the second complaint: I’ve had an issue or two where I’ve had to change my contract/arrival times with the rental company. I’ve never been able to get to local branch where I reserved my car. All of the listings for that location are SEO optimized to go to the national number, which then forwards you to sales rather than customer service. After getting tired of the whole pricing, I was told by the agent at the ROC Budget Rental company that the new price was based on “Market Demand.” That ignores the fact that by not picking up the car they now have more supply and less demand. They attempted to reprice a week long rental that was originally $172 to $530+. Finally, after threatening to cancel my reservation for next week, he made a (his words) “manual one time price fix.” I knew the market price for a last minute car rental. It was $350 via Alamo. Are they any better? We’ll see.

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.

The Pitfalls of Testing

For the most part, testing is a great thing that is a surefire way to improve software quality. However, I’ve found that there can be three minor pitfalls when it comes to testing. I’m sure there are more, but these are the ones that I’ve experienced.

When running the tests, your current runtime environment is based off the testing class path. This means that when you are using refactoring, the classes that the test cases are contained within can appear to be valid packages within your application. For example, when recursively searching for a listing of classes by using reflection, the test classes will show up. This is an important thing to note, and to remove the test classes in your cases, when you’re confirming the results of this process. In addition, it is possible to use reflection to see and initiate test cases from the application logic, something that should not be a valid operation in unit testing. For example: If you had a Factory class to initiate only the classes within your JAR file, you could pass in a reference to a test class, and it would initiate it. This would produce undesired behavior.

IDEs consider test cases to be a usage of code. This makes it more difficult to spot dead code in your project. Dead code slows down production time, tends to be non-conforming with the current code base/philosophy, and may be used by an ill-informed developer later.

As of the current JUnit version (4.11), there is no way to disable a test and have a warning created for this state. The only two options for this are to let the unused test case fail intentionally, or to use the ignore annotation. Intentional test case breakages performed by an intentional fail method within the test case, or leaving the functionality broken. Unfinished test cases [which would warrant this situation], should not be left blank, they will show up as a passed test case. Empty test cases should be shown as an error, but are not. This StackOverflow question discusses the Ignore annotation more; however using @Ignore leaves unused test cases, which the developer is responsible for keeping up with. Having a broken test case inflates the failed test case count, and may cause valid test failures to be overlooked.

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.