Software Shop Success Checklist

Teams of people need structure. Humans are imperfect, forgetful, prone to mistakes, and often cut corners for convenience or “time saving”. Yes, structure and organization are important for teams of programmers and software engineers no matter how many times your leaders have declared that you’re an Agile (with a big A) and agile (with a little a) shop.

Ask Questions during Interviews

It’s easy to get swept up in the marketing techniques that a lot of software companies use during the recruiting and interviewing phases. Maybe you’ve been eyeing a particular position for awhile and finally have the opportunity to make it through the on site gauntlet. You may also be desperate for a job for one reason or another. Regardless, it pays off in the end to make sure you’re aware of how the business operates under the hood.

These guidelines are especially important if you’re signing on as a full time employee or with a company whose primary business is something other than writing software. The former because it’s mentally more difficult to give up benefits, vacations, and a consistent salary should you find out that you’re really not enjoying the job. And the latter because businesses that focus on something other than software are notorious for, frankly, not giving a crap about their various IT/software departments.

During the interview phases of your job search, make sure to take time to ask the interviewer your own questions. Many people overlook this part of the interview phase either because they’ve been in the interview process for 6 hours straight and want to go home, or they just don’t care. From personal experience, it’s a mistake to miss out on the only time you’ll be able to get details about the business, the team, and the project that you may be joining.

Define and Enforce Coding Standards

Many times, software shops will discuss their coding standards verbally but eventually get tired of repeating it to new hires. This means that on-boarding processes are abandoned, and new hires are left to come up with their own standards which may or may not conflict with the previous verbal standards. If your shop decides on a set of standards and holds developers to those standards during code reviews, everyone on the team now and in the future will easily acclimate to the various projects across the team’s code base. This reduces friction and increases coding efficiency.

Examples of what should be standardized include:

  • Comment styles and lengths
  • Names for projects, assemblies, classes, interfaces, and variables
  • Project architectures and structures depending on needs
  • Endpoint names and structures in APIs

This list above is definitely not exhaustive, and I’m certain that you could come up with a lot more to standardize. Remember not to go overboard. You don’t want to inflict too much regulation and pains on your teams to the point that they feel incapacitated.

Code Reviews and QA Standards

Reviewing what has been checked in and what is slated to be deployed are two very important and often overlooked aspects of software engineering.… Read more

Working “Crunch” Overtime Might Not Help a Team Deliver

The deadline is approaching. Your project is a mess. Your team doesn’t know if delivering on time is going to be possible. Your director has a genius idea. Everyone work overtime with no plan in mind! Have you ever been in such a situation? It’s quite common if you work in IT or software engineer. For some reason, management thinks that everyone working more hours is directly proportional to more productivity.

There’s a problem with that. The common 40 hour workweek was created from evidence-based research. For nearly all professions and activities, the productivity, efficiency, and general output of a worker drops off dramatically after a certain number of hours in a day. It’s easy to simply say, “Work more hours!” It’s a lot more difficult to use a logical approach and discover the root of what’s causing delays in the project.

It’s disheartening when your director or boss says something like, “We signed up for this profession. We knew what to expect when joining this company. Every project has a “crunch” time for people to work overtime. That’s the industry!” I’m sorry, but I don’t buy that reasoning. If projects are consistently late or require “crunch”, then something has been fundamentally wrong with the project planning from the beginning each and every time.

Look, I get it. Really, I do. People want to solve problems. In an engineering profession, people have a genuine interest in producing solutions to problems. Unfortunately, a lot of the solutions attempt to fix the wrong problem. Projects are behind or off track for a lot of reasons, none of which are solved by simply throwing more person-hours at it.

  • The initial product requirements were not well documented
  • The schedule is poorly planned, maintained, or enforced for the life of the project
  • Constant employee turnover due to poor working conditions, culture, or mentoring
  • Little to no documentation of features and development
  • Little to no knowledge transfer between new and outgoing employees
  • Little to no interest from leadership and veterans to mentor employees
  • Little to no enforcement of working standards from leadership and veterans
  • Little to no involvement from the business and users

That’s not even a comprehensive list. That’s just from the top of my end due to personal experience. Ask yourself which of those could even begin to be solved by working overtime during a “crunch” period. If you guessed zero, then you just won a prize. Most of the solutions to the above list can only be solved by changing the culture of the company and hiring people with an express interest in the time-honored tradition of steady, cautious, and logical construction.

Make sure you ask the right questions during your interview: “Is there a lot of employee turnover? Are project standards established and enforced? Do you have good documentation? How do you gather requirements? Is the business involved in your project?” Run quickly if any of these throw up your red flag. You’ll thank me and your sanity.… Read more

Open Offices Aren’t Always the Solution

What’s with the latest craze in the office organization of the service industry? Are we really going back to huge, open spaces with no sense of privacy at all? With companies like Facebook, Google, and even smaller companies like Valve praising the open office concept, it sure seems like it will be here to stay for awhile. That’s unfortunate, because open offices suck!

The Concept

Look, I get it. Someone saw the cube farms and said, “Why are all these people locking themselves away? We need to be more collaborative! Our products are failing because no one is talking to each other. Tear down these walls!” Down came the walls. Soon enough the facility planners were shuffling desks together, removing all partitions, knocking down walls and replacing them with fishbowl style glass walls, and preaching Agile processes. All the while the seasoned veterans are running for the doors as quick as possible.

The Good

There really isn’t a whole lot that I like about open offices (as an introvert), so this might be a biased section. However, I will say that open offices do encourage you to talk to people near you that you normally wouldn’t. This can be a good thing in the sense that you get to know your coworkers. But when a project needs to be worked on diligently, the open office spaces seem to encourage people to just chit chat about random stuff all day. Joking, yelling, talking loudly, and throwing stuff around is just a little bit of what can be experienced in an open office. See, I wasn’t really a good candidate to praise whatever virtues open offices may have.

Is this my desk? Cool. Wait, why is the guy across from me turning on his radio. Oh wonderful, I guess I’ll learn to like Insane Clown Posse.

The Bad

The walls weren’t the only thing to fall. Efficiency, privacy, and and overall sense of quiet-time came crashing to a halt. Where you once had the opportunity to sit, relax, and think on a problem without much interruptions, you’re now constantly bombarded from all senses. Annoying coworkers throwing a beach ball around? Yea, it’s in your line of sight. People blasting music because it’s “collaborative?” Sorry, you just have to put up with LET THE BODIES HIT THE FLOOR until 5 PM. Deal with it. Forget about concentrating on anything useful when this kind of behavior is tolerated or even encouraged by the management.

All Things In Moderation

To be honest, I’m sure there are varying levels of the open office concept. Some offices have no partitions, low partitions, half partitions, or see-through partitions. Others may have only glass walls, some glass walls, or no walls. I’ve worked in the most extreme concept of open offices in which the entire office is one large space with no separation between desks and only glass walls between other rooms.

There were literally no opaque walls in my office at the time of working there.… Read more

Completing Three Major Projects in One Year

I think it’s important to brag about any project that you manage to take from idea to completion. Many people (myself included) have a ton of ideas, few of which become something, and even fewer of which are actually finished and out there. So you should take any opportunity you get to shout out anything you’ve completed.

Built a website? Cool. Remodeled your kitchen? Nice. Wrote a short story? Awesome. Get out there and tell people!

I know the feeling of wanting to start something new every day just to forget about any mistakes you might have made in the previous day. It’s all about start, start, start. It’s never about finish, finish, finish. I guess sometimes we feel like “new” is better than “old” even if that “old” thing has potential.

Without further ado, these are three major projects that I managed to complete in late 2015 and early 2016. They’re not much, but hey, they’re mine!

Twolips Dating

TwolipsDatingSplashTwolips Dating is an online dating community aimed at those who want to find others based on their knowledge and skills. Find yourself attracted to someone really good at math? Awesome. Find people in the community who have answered a ton of math related trivia questions and quizzes. Sign up for free.

Or just check out the blog to follow updates until you’re ready to start.

Safer Stash

SaferStashSplashSafer Stash is an online encrypted virtual storage for your physical stuff. The image above does a good idea of succinctly describing it. Think of it as an online backup for receipts and images of your expensive belongings so that you’re protected in the event of a loss or other need. Sign up for free.

Or just check out the blog to follow updates until you’re ready to start.

Dota Database

DotaDatabaseSplashThe Dota Database is a site dedicated to Dota 2 enthusiasts and “stats nerds” who are interested in the internal data of Dota 2. You can quickly look up hero stats, item stats, cosmetic item stores, live matches, and more directly data mined from the Dota 2 Game Client and Steam. There’s absolutely no cost to using all the features.… Read more

Agile Development isn’t a Silver Bullet

Buzzwords are the worst. The absolute worst. They seem to be something that some higher up read about and decided to preach to his or her employees. Inevitably the buzzwords will end up on job requirements (even if the job has nothing to do with that buzzword) or talked about endlessly during job proposals and interviews. Honestly, it’s a huge red flag if someone repeats a certain methodology, process, or philosophy without justifying the context. “Agile” is just one such buzzword that seems to be really misunderstood and misapplied.

When Agile Becomes a Burden

What is this “Agile” thing? Supposedly its a software development methodology designed to react to a faster paced and rapidly changing form of software construction. Perhaps your requirements are in flux, or your customers don’t really know what they want until they see something in development, or you’re just really interested in that “scrum” word you keep hearing about on various tech blogs. Regardless, you really want in on that sweet, sweet Agile action.

You hire some scrum masters, software engineers (remote is OK), QA engineers, technical writers, and business analysts. You setup a scrum board. You preach the tales of development sprints, user stories, and research spikes. You do all the things that you learned during your 2-day Agile bootcamp in Silicon Valley. Oh man, you’re on a roll you think to yourself. There’s no way a project can fail if I know of all the problems in our daily standups!

Over time, some cracks start to appear in your process. Why are we revisiting a piece of code from three sprints ago? What do you mean you didn’t put in proper error handling and documentation? You had to meet your sprint deadline (which includes development + deployments + QA + code review + documentation + user acceptance). There’s no time for “clean code” and algorithms that “make sense.” Just get that stuff checked in and commit to your next sprint, damn it!

Maybe it’s a cultural thing. Maybe it isn’t the Agile process at fault here. Maybe you’re just misusing it.

Knowing Your Gaps

Agile is a process with many faces. There are a ton of variations, all or none of which may apply to whatever project you have on hand. The lesson here is that you shouldn’t mass apply any one Agile methodology to your project without careful consideration of what the project is, what the project’s goals are, and how the people on the project like to work. Take some time to analyze these facets and build a process around your projects, cultures, and environments.

Just because some other organization saw a billion percent increased revenue after adopting the most recent buzzwords doesn’t mean that the exact same process will yield the exact same results for you.

Look inward before you put that buzzword on your job requirements.… Read more

Get Over Your Fear of Remote Work

This article is aimed at both employers and employees alike. In some circles of the technology industry, there seems to be this pervasive anxiety when discussing the activities of remote workers. In fact, certain CEOs have gone so far as to reign in the egregious act of working remotely by effectively banning the practice altogether. I’m sure he or she sent out a memo including words like “agile,” “synergy,” and “cohesion” to seal the deal.

As the complexity and needs of software continues to grow, companies need to be willing to hire workers whose only option is to work remotely due to location or other life circumstances. Rejecting a possibly great candidate because they are unable or unwilling to relocate across the country is a huge loss for many reasons.

First, the employer missed out on an opportunity with a great candidate. Perhaps that person would have been responsible for saving the company a lot of money or publishing a renowned product. Second, by hiring a remote worker, the employer can forgo the cost of physical on-boarding, providing a phone, providing a desk, and providing a location for which the employee can conduct work. Instead, the company only needs to provide hardware and software to get the employee started. Third, remote employees have far more time to actually do work without having to worry about travel time to and from the work location. In some instances, traveling can consume hours each day depending on the commute distance. Instead of wasting time in traffic, the employee can spend time on work.

Yes, there are downsides to remote employees, but many of them can be mitigated by occasional trips to the main office and conducting shared activities on remote communication technologies like VOIP and instant messaging. When talking to people who are skeptical, the first fallacy that I hear is, “But I need someone to be physically next to me to get my work done!” To be honest, this sounds like a personal problem. If you are unable or unwilling to get work done without physically seeing your coworkers, then you need to work on adjusting away from such an attitude. Between webcams, phones, instant messaging, desktop sharing, and remote desktops, there should be almost no excuse to having difficulties communicating with remote workers.

Remote work is going away. I would argue that it will increase in necessity as population increases, cities become more widespread, suburbs move beyond reasonable commuting distances, and job opportunities become more spread out. There’s simply no way to avoid the globalization of our economy. In order to adjust appropriately, we all need to be more accommodating to qualified candidates who would prefer or must work remotely. Your company may depend on it.… Read more

The misguided nature of redesigning a user interface every year

I am what I would consider tech-savvy. I tend to dabble in different technologies, semi-early adopt the latest operating systems and versions of software, and generally enjoy testing out new features in computer-based environments. With all that said, even I find it annoying when “designers” find the need to redesign and restructure a product’s user interface on a yearly basis.

Here’s a series of tweets from Google’s VP of Product Design which perfectly illustrate his approach to how things work.

Despite what he says about “having no beef with how Windows looks”, he contradicts himself by first stating that he dislikes the fact that it is “basically XP with a flat design skin.” Obviously the guy is allowed to have his own opinion, but his opinion will spill over into his work on Google’s product designs. That isn’t too surprising given the number and frequency of user interface changes to Google’s products and services every year.

And therein lies the problem. The vast majority of Google’s products occur on the web and on their Android platform. What do these two platforms have in common? Minimal control over which version of a product you’re currently using. This is especially true on the web where you literally have no idea what a website will look one day to the next because you aren’t informed of any “pending upgrades.” On Android, you’re stuck with nagging updates which may or may not completely change your workflow due to a redesigned user interface.

I realize that modern age personal computing is less than 30 years old, and that mobile computing is even newer. There’s plenty of room for improvement. I don’t want to be “that guy” who wants everything to stagnate and never move forward. That said, I see no good or compelling reason to make radical user interface as seen in Windows 8 and Google’s Material design. Why not ease people into a new design rather than dropping a huge set of changes on everyone?

Many people are resistant to change. That much is obvious just by talking to users of a system or reading the reviews of a product directly after launching a new version. And while much of the grievance is simply because of change itself, there are legitimate concerns from people regarding changes which affect their lifestyle and workflow. Changes should be eased in and tested on people at large scales to get perspectives from beyond the “Silicon Valley Bubble” which tends to act as an echo chamber.… Read more

3 Types of Questions You Should Never Ask During an Interview

So your boss came to you and told you to conduct an interview for a new hire. Or maybe you’re actually the hiring manager. Guess what? These suggestions apply to everyone! Based on my experiences with many technical interviews, avoiding these 3 types of questions applies to anyone wanting to steer clear of legal issues and attract the best candidates with the most accurate predictions of success.

I won’t make any claims about being able to predict applicant performance in specific scenarios. This is mainly because studies have shown such predictions to be difficult to obtain regardless of the type of measure utilized during the interview process. While interviews can be a good predictor of how an applicant will apply knowledge in a general and broad scope, it’s extremely difficult to judge whether or not said applicant will succeed with a specific technology for a specific project that your company has in mind. It’s even more difficult to predict when you’re using bogus, irrelevant, and nonsensical questions as a measure.

My advice is to stick to standardized, measurable, specific, and proven questions that are directly relevant to the job position and company as a whole.

1. Personal Questions

I’ve already discussed this one in an article about learning to conduct interviews, but I want to repeat it because it’s an important one. I’ve personally experienced and heard stories about some interviewers who feel that it’s appropriate to ask the applicant about their personal life including hobbies, what they do in their spare time, family life, age, birthdays, religion, and more. These topics just aren’t relevant to whether or not the applicant is fit for the position. In fact, asking about age and marriage can land you in legal hot water if an applicant decides to use that against you in a discrimination case.

Spare time and family life can be indicators of how available an applicant will be after hours. Someone who has a lot of hobbies and a few children probably isn’t willing to work tons of overtime. Without being able to ask about these, I can already hear the slave drivers screaming that they won’t be able to judge whether or not an applicant will be available 24/7 because they have a family to support. While that’s a topic for another day, rest assured that morale and overall productivity at a company with such policies is doomed to stay in the pits.

Making comments about age and asking about birthdays is just asking for trouble. It’s common for companies to look for the youngest possible applicants in the name of so-called “culture fit.” What they really want is someone who is still in “college mode” with no responsibilities beyond work and someone who is willing to take rock bottom pay out of either desperation or naivety. Silicon Valley and Wall Street will often call these people “passionate” to place a positive spin on the fact that they’re trading their free time for a slim chance at riches.… Read more

Teach your employees to conduct interviews

Conducting regular interviews is essential for any company that wants to find top talent. Not only is there a possibility of finding a random gem, but it guarantees that your business stays informed of the job market. How many people are looking? What are they looking for? Is my business situated to attract the right people? Such an important thing should probably be conducted by knowledgeable individuals, right? Hey, that’s just my opinion.

As someone who has experience being on the receiving end of the job interview onslaught, I want to take some time to give advice to those who conduct the interviews. This obviously comes from the perspective of the receiver, so I can’t help if my opinions are a little biased. Regardless, I think that there’s some valuable information on the other side of the table for those who are conducting the interviews. As a frequent interviewee, it it’s painfully obvious when an interviewer is not interested or isn’t trained well in conducting interviews.

Read the Resume, Please

I’ve noticed an alarming trend of some interviews being conducted without any references to or knowledge of the applicant’s resume. You know there’s some important stuff on there, right? Larger companies seem to be particularly guilty of this. It’s probably a symptom of receiving too many applicants to filter through at the beginning stages. I totally get that. I sympathize with companies that receive thousands of applications each week. But to ignore important background for applicant’s that pass various phases of the process seems silly.

Honestly, I don’t understand why some on site interviewers don’t read or reference anything about resumes. Clearly the applicant has impressed you enough to invite them on site to go through the gauntlet. Yet, you’re not interested enough to ask, at the very least, some minimal questions about the applicant’s background and experience? It’s your chance to get to know the person beyond the academic knowledge that they’ve spent hours memorizing for the interview.

I understand the need to judge an applicant’s ability to perform the immediate tasks through question drills, whiteboard quizzes, and comprehensive discussion. However, by ignoring the important mine of information in an applicant’s resume, it seems like an interviewer would miss out on plenty of opportunities to confirm stories with the applicant. This gives the applicant a chance to discuss their past experiences and projects in complete detail. From this, one can judge an applicant’s ability to hold a conversation, discuss technical details, translate complex project information to a third party who isn’t directly involved with the project, and see if anything in the resume is bogus.

Be Interested or Act Like You Are

Being on the receiving end of an interviewer who wants nothing more than to leave is an awful feeling. As an applicant, you start the interview in an already nervous state, and the last thing you want is someone asking you questions who couldn’t care less about the answers. Why would companies go through the trouble of scheduling time to interview when their scheduled interviewers simply don’t want to do it?… Read more

If you’re a professional, communicate like one

So you’ve landed that job after reading my interviewing tips, right? When you start that job, what skills do you think will be necessary for success? Obviously, you’ll need the relevant knowledge, technical, and physical skills to get the job done. Unfortunately, one very important part of a successful employee is often neglected due to ignorance or indifference. Based on the title of this blog post, you may have guessed that the often lacking skill is “communication.” To clarify, the following advice can be applied to many types of jobs, but focuses on technology and office-oriented service positions.

It’s a shame that this skill is so poorly understood by many professional workers and academics, because it’s absolutely critical to conveying our ideas, knowledge, processes, and skills to colleagues and coworkers. Here are just some of the scenarios in which good and proper communication is key to success. These are just the things that I thought of in the last 45 seconds! The interested readers among you can probably come up with many more relevant examples.

  • Transferring domain specific knowledge to new workers or replacements
  • Training new workers on domain specific processes
  • Conveying company policies, rules, and regulations
  • Working within the immediate team to provide regular updates, feedback, and support
  • Communicating with remote coworkers, customers, and clients via video conference, teleconference, instant message, email, and phone

Transferring Knowledge and Training

There are often circumstances either within your control or beyond your control that may require you to transfer domain specific knowledge to a coworker, a new hire, or a replacement. As the resident expert in the domain, it’s important to yourself and your company that you accurately transfer knowledge to other people. Think of all the knowledge you’ve gained in the years that you’ve spent at the company. It’s a huge loss to everyone involved if you simply walk away without assisting others in learning enough about the domain to partially fill the giant hole once you’re unavailable.

If it’s the first time such knowledge transfer is occurring, make sure to document each important step so that future transfers are nearly hands off. This will require less time dedication on your part after the initial training sessions are completed. Additionally, you are no longer considered a point of failure in the “knowledge tree.” If you’re out for the day or spending a few weeks on vacation, the ease at which another person can pick up the slack is increased due to well documented processes. This is especially important if you’re leaving the company. There’s no way for people to contact you after you’re gone, so it’s critical that you spill your knowledge to paper.

Teamwork

A huge part of teamwork is good and regular communication. This is especially true if your coworkers are relying on you to finish a portion of a project before they can proceed or complete. Without giving regular updates, the rest of your team will be misinformed on where you stand in the schedule. Think about establishing a monthly progress report for larger projects, weekly progress reports for smaller projects, and possibly bi-weekly stand up meetings between immediate team members to keep each other informed of relevant and interesting information.… Read more