Header Image -

Monthly Archives

7 Articles

Code all day, test all night.

by dave 0 Comments

The last few weeks have been 90% beating my head against code, and 10% moments of bliss when things finally work. It seems like everything that should take an hour to get done takes a day, and what should take a day takes a week.

But I am seeing the light at the end of the tunnel – I have a plan of attack to debug what I hope is the last of the issues in the morning, then I can start to really test everything out, finalize security, and hopefully release one of my current projects out to more people as a fully functional system.

The real question this raises, and the reason this post is marked as a “Work At Home” blog post is…

Who am I talking to, anyway?

I’ve been thinking about my reasons for writing, and I have found that I really have 3 audiences in mind when I write:

1) Other people who may be just starting to work from home, and may want to hear some perspectives from someone already doing that. Sometimes I’ll have something useful to say… other times, I just express what is going through my head as someone who works alone all day.

2) Younger folk who may be able to gain something valuable from my General rants on technology.

3) Myself. I just enjoy writing sometime as a way to relax.

This post started as a mix of 1 and 3, but mostly I am just writing to myself, late at night, after staying up way too late to knock out a few items that I really wanted to get done.

New Laptop

by dave 0 Comments

I just purchased a Lenovo Yoga 2 Pro to help me with a few things:

  1. To allow me to work away from my basement office
  2. To let me work from Florida next month.
  3. To let me test multi-user real-time apps better.
  4. To let me test touch-screen UIs better.
  5. To free up my old laptop for my kids.

And it occurred to me that even though i purchased the lower end model of these, it is still an extremely impressive piece of hardware. Especially when I think back to one conversation I had in college…

I was talking to a friend who was a few years older than I – he was a software engineer for Electric Boat, where they designed submarines. He was telling me about their system with 2 GIGS! of memory, that was used to render the designs. 2 GIGS! that was so massively impressive that I could barely imagine it.

And now, this 1 pound laptop/tablet holds twice that. The computing power that I can pick up on my lunch hour is more powerful than the military’s largest systems when I was in college.

That is really kinda impressive.

The Myth of Developer Productivity

by dave 0 Comments

Many discussions that I read online talk about making sure that your products are designed in such a way that they are easy to maintain, in order to maximize your developers’ productivity. In theory, that sounds good — efficient development is a good thing. Productive workers are a good thing. Speedy development of new features is a good thing. So what is wrong with aiming for productive software development as a goal?

The problem is that productive developers should not be a goal in and of themselves. The actual goal is to be able to respond to the needs of your organization, and to be able to produce products that meet all the customer needs and internal needs, avoiding turning your software development into a roadblock to your plans.

The danger of worrying about productivity at the developer level is that you can end up spinning your wheels on refactoring, using,  new frameworks, updating existing components, improving your toolkits, etc…  you can spend so much time making the code itself such an impressive piece of work that you barely noticed that you haven’t delivered a new feature to your customers in months.

The other flaw with focusing on developer productivity is based on math. How many developers do you have vs. customers? How many hours do your developers spend working on your products vs. the hours your customers spend?

Maybe if you are a startup, with a small customer base, it does make sense to focus on the product development more heavily. But once you reach a certain critical mass, for every developer hour you spend, you customers spend hundreds of hours on your product. You have much larger gains by focusing on the customer.

Let me be clear – I am not saying that productive developers are bad things. Efficiency is good. I am saying that savings a few dozen or even hundreds of developer hours pales in comparison to saving thousands or tens of thousands of customer hours.

Developer productivity is a good thing. But not a critical thing.



Tweaking my Daily Routine

by dave 0 Comments

Working at home is something that requires constant incremental improvements. Sometimes you make an improvement to your office or your tools and equipment. Other times you adjust details of how you work. The trick is simply to identify areas of improvement, then act on them.

Today, it is time to try some adjustments to my daily routine to try to resolve two problems.

The problems are:

  1. My afternoons are never as productive as my mornings.
  2. I am in poor health.

Problem #1 – Mediocre Afternoons

One thing I have learned is that I code better while caffeinated.  I am well aware that this is an addiction and is an unhealthy thing, but that is not one of the problems I am trying to solve today. But what I am going to do is adjust the timing of when I drink caffeine. I am going to move my daily caffeinated beverage to lunch instead of breakfast. This will give my brain that jump-start when I need it — in the afternoon. The hope is that I can balance out the productivity of my day and give myself a more steady working day instead of an uber-productive morning followed by a lame afternoon.

Problem #2 – Health

I’ve had significant health issues over the past few years. I’m finally healed from most of my physical injuries, and have found a diet and some supplements that has me feeling pretty good without being on drugs. However, over the course of it all, I gained a ton of weight and lost all of my fitness. I need to get back on track. So I am changing my lunch break into an exercise/lunch break, where I will hop on an elliptical machine for a while each day at lunch.

Also, I just started my kids in a martial art class. So it is time for me to get back into my practice as well. Luckily, despite not having practiced in 3 years, I’ve kept all my notes. So I am going to spend some time each evening practicing my martial arts.

Both of these activities will increase my chronic pain levels, but I’m hoping that it leaves it manageable enough to get back in shape, thereby taking the stress of extra weight off my body, and eventually the pain should decrease and all will be well.

So my routine that I am going to test for the next couple weeks is going to be:

  1. Wake up, do my daily web reading, and have breakfast.
  2. Start my work for the day.
  3. Around 11, break for exercise.
  4. Have my lunch with a caffeinated beverage
  5. Work until it is time to take kids to kung fu.
  6. Practice my own martial arts
  7. Spend evening with family
  8. Put kids to bed
  9. Finish up any work for the day
  10. Go to Bed.

Hopefully this will result in a healthier me, delivering more code, faster.

Taking Accountability as a Software Developer

by dave 0 Comments

One of the aspects of being an old guy writing code is that I see a lot of behavior from younger and/or less experienced developers that comes off as unprofessional to me. I try not to judge anyone for being unprofessional – I was no better when I was young. But I had older people around who would occasionally call me on my behavior and explain to me that there may be better ways to handle things.

Hence this blog post – a few pointers on taking accountability for your own work.

The over-arching rule is that you are responsible for the results of your work.  Whether your work is working as you intended or not, when one of your users has a complaint about it, you need to address that complaint.

Here are some typical comments that I see in online discussions or status updates, and how I would have handled them differently:

Disclaimer – people can probably rip my responses below to shreds, too. The point is to take responsibility for your own work in a polite and professional manner, and these scenarios are just examples to illustrate that point.

1) In the case of downtime of your app.:

  • Bad – “Our data provider went down. It wasn’t our fault.”
  • Better – “We had some problems with our infrastructure. We have identified where the problems lie, and are working with the correct parties to correct the issues.”
  • Best – “We identified the root causes of the problems, and our internal staff and vendors are working together to prevent future occurrences of these problems.”

2) In the case where a user’s environment breaks your code.

  • Bad – “It works on my system.”
  • Better – “The problem is due to differences between our systems. Can you work with me to help troubleshoot it so I can fix it for you?”
  • Best – “I have found the problem, and updated the product to work in your environment, as well as updated our test processes to ensure we test for your environment in the future.”

3) In the case where a user thinks something is broken because they don’t understand your system.

  • Bad – “It is working fine. “
  • Better – “I see where the confusion is coming from — that feature actually works like this…. <insert explanation here>”
  • Best – “Although this is working as we intended it, clearly that wasn’t what you were expecting. Can you explain what you were expecting, and what you were trying to accomplish so we can improve our product?”

4) In the case that a bug is actually in a framework you are using, not code you wrote directly:

  • Bad – “This is not my bug. It is a bug in X”
  • Good – “This is a problem with X. We can work around it by doing Y until they have a chance to fix it.”
  • Best – After working around it in your code, working with the developer of the framework, writing the bugfix yourself and submitting it, or putting in a whole new framework if need be, to resolve the issue…. “Thanks for finding this for us – we have put out an update that should resolve it for you. Please let us know if the update is working for you.”

The bottom line is that at some point, someone is going to take responsibility for problems with software. As a coder, you are often already the 2nd or 3rd person someone has dealt with when looking for help. Passing the buck frustrates the customer, and can frustrate your coworkers. Taking accountability for problems will improve your code, improve your understanding of the larger infrastructure in which your code operates, and help you understand your customers better. These will all result in a better product, and will make the difference in how people perceive you – as just a coder, or as “the guy” to go to to get things resolved.

It should also be noted that taking accountability does not mean taking blame, nor does it mean that you are responsible for the fix. Sometimes it really is someone else’s job to fix the problem. But there is a huge difference between responding, “Let me help get the correct people together to get this fixed” vs. “Not my problem – Ask Joe.”

And yes, there is a flip side to this, wherein if you own everything that passes by you, you’ll never get your own job done. The key is the perception to your customer. Do they feel that you care about helping them with their problems, or not?  

Details of what problems you own, and what you pass on are going to vary based on your organization and your role. My best recommendation is simply to take every issue seriously.  Make sure that you understand the problem, verify whether or not you have control of fixing it, and then respond in a way that best supports your customers.