My thoughts as an enterprise Java developer.

Friday, December 23, 2016

Better show that a password is being entered

Terminals need a better way to show that a password is being enter in order to reduce the chance that a password would be accidentally entered somewhere incorrect.
The whole screen should have some indication that a password is being entered. I.e. Dim everything but the password field. This would reduce the problem of accidentally typing your password into chat when you thought another window was active.

To log or not to log

To log or not to log?
That is the question.
Whether is nobler to in the Sumo to suffer ups and downs of outrageous quantity, or to take out logs against a Sea of repetition.

Wednesday, August 10, 2016

Tight scoping of constants

How do you declare constants that are only needed in a small scope (function or smaller)? I declare them in the tightest scope as final with an all-caps name. I.e.:

final int THRESHOLD = 1000;

That coveys the intent that it is a constant but minimizes scope.

Disable new UI components until the user has had time to react to them

How often do you use a program, decide to take an action (I.e. Press Return), and then have something popup and use your action before you even have a chance to read the popup? I hate when that happens because I don’t even know what I told the computer to do.

Input on a new UI element should be disabled for a short time to ensure that the user actually wants to take action on the new UI element. The delay has to be just long enough for the user to realize that the action may do something differently and not too long to slow down users who know that the popup is coming. So the delay should probably be a few hundred milliseconds.

Saturday, July 23, 2016

devopsdays 2016

There was a lot of useful info but these are the things that stuck out to me.


As a developer it seemed that vast majority of the content was for people with an ops focus. We need to help with better content for the dev side of devops. Based on a raise of hands the split was about even for conference attendees.

Working with Marketing and Sales:

  • Invite to demos. Record video and details in documentation so they can review later
  • Roadmapping meetings with representives from all groups
  • Get rid of the game of telephone and bring everyone together. Talk to other groups directly instead of depending on others to always filter their content.
  • Know other groups: from goals to pains

Making good choices with software

  • Code is the enemy
  • Resist software sprawl
  • Control/friction for new things on critical path
  • Correlate risk with startup timeline and use risk on differentiators
  • Replacement plan must prioritize getting rid of the old
  • Use humans for core features
  • Celebrate removal, deprecation, and refactoring because celebrated patterns will be repeated

Open Spaces

We need more developer focused discussions.
I started a discussion on monitoring for developers. Others used different tools like Datadog and Splunk that may be interesting to check out. Some developers had much less access to production – especially if production had sensitive data and needed to have PCI compliance. It is important to use both tools and provide instrumentation monitoring in code.
In internal discussions another developer-focused topic thrown out was how development deals with ops scripts. They aren't our main focus and are often written differently than a developer would write them.


I'm interested in both the methodology and outcome of https://implicit.harvard.edu/implicit/takeatest.html

Friday, February 13, 2015

Thursday, February 20, 2014


CodeCombat: "Learn to Code JavaScript by Playing a Game"

Tuesday, January 14, 2014

Preferences/Settings should be minimized

Allowing a user to change how an application works by only going into preferences/settings should be avoided.

  • Most users won't even look there so features will be underused which is a waste of development resources.
  • Try to prompt the user to change their preference when they do a related action. i.e. if there is a preference for the number of items to show on a page and the user changes the dropdown to show a different number of items on the page then ask the user if they would like to update the preference to the new value.
  • When prompting the user, avoid making the user click an extra time. Instead of doing a popup, just add text that prompts the user.

Tuesday, December 10, 2013

More interesting wait screen

I have seen many wait screens that do the job but are boring. I think it might work a lot better to make a wait screen that displays something interesting. Maybe draw a fractal or present a simple game. If there is something interesting, the user shouldn't mind the wait as much.