Registry Hacks

These are some of my favorite Windows registry additions:

Add Notepad as a right click menu option to open any file:
CLASSES_ROOT\*\shell\notepad\command\:REG_EXPAND_SZ: %SystemRoot%\system32\notepad.exe %1

Add DosHere as a right click menu option to all folders to start a command prompt in that directory:
CLASSES_ROOT\Directory\shell\DosHere\command\:REG_EXPAND_SZ: %SystemRoot%\system32\cmd.exe /k cd "%1" && title %1

PayPal makes man $92 quadrillion richer (temporarily) | Technically Incorrect - CNET News

PayPal makes man $92 quadrillion richer (temporarily) | Technically Incorrect - CNET News: "Please imagine, for example, how giddy Pennsylvania PR executive Chris Reynolds must have felt when PayPal made him $92 quadrillion richer -- $92,233,720,368,547,800 richer to be precise."

That is $41.92 more than the max amount of money (in pennies) that can fit in a signed 64-bit number.

Deprecation Plan

Once a method is deprecated, Java seems to have no further plans for removing it before Java 2.0 (if that ever happens).

I suggest the following steps be done by default:

1. Deprecate the method (Java already does this) and generate info log about using the method
2. At the next major release, increase the logging level to warning
3. At the next major release, increase the logging level to severe and remove from compile time libraries
4. After 2 major releases, throw an exception in the runtime (with useful message)
5. At the next major release, remove from the runtime

For example, the old Java 1.0 AWT event model was deprecated in 1.1. It this plan was followed, it could not have been used in code compiled in 1.3 (3 years after deprecation) and would have thrown an exception with the 1.5 runtime (7.5 years after deprecation).

Of course the timing of those steps may have to be tweaked (i.e. quick releases, widely used methods, etc) but it can be the default blueprint for getting rid of old code.

Do you prefer the current plan of leaving deprecated methods until Java 2.0 or do you think we should have the above plan or another plan for removing them.

Why We (Still) Believe in Working Remotely � Blog – Stack Exchange

Why We (Still) Believe in Working Remotely � Blog – Stack Exchange: "If you’re hiring for technical positions, hiring remotely is the best-kept, blindingly obvious secret for finding people."

"when going to work is as simple as walking upstairs (pants optional, but recommended) people just tend to put in more hours and work more productively."

"Our remote developers are some of the most argumentative people in the whole company, because we hired them to be that way. We like opinionated people. Opinionated people find things they care about to work on and make sure you know what they think, which is essential if you’re not sharing an office together."

"If even one person on the team is remote, every single person has to start communicating online."

Java Performance Tuning News April 2013: Engineering

News April 2013: "If engineers could build a bridge, and for not very much cost could test it to destruction by driving something heavy over it but with no casualties and leaving no debris; and, finding that it didn't handle the heavy vehicle, could just work on buttressing some aspect of the bridge, and for not very much cost a couple of days later put the next version of the bridge up for testing, it wouldn't surprise me to see bridges developed in just that way. And finally I realised that software engineering differs from most other types of engineering in a very specific way. We have a cost model that mostly encourages us to build incomplete constructs, because it's relatively cheap to fix. Where this doesn't apply (nuclear power plant management, aircraft fly-by-wire systems, etc), development times are much longer and much more expensive (for the equivalent amount of software).

Is this good or bad? I make no judgement. But I will observe that in the last 20 years the way people live in large chunks of the world has dramatically changed from all the half built continually buttressed software engineering projects that make up the web, the world of apps, and all that we can find in cyberspace, on our laptops, desktops and phones."

Interfaces: balancing debugging vs. customization

What are the cost vs. benefits of creating interfaces and how to balance them. I am only considering cases where interfaces are optional and aren’t needed.

Benefits:
1. Simplify interaction: Easier to see how to use a List than an ArrayList
2. Make testing easier because replacement implementations can be used
3. Can make future changes easier

Costs:
1. Harder to understand what the code is doing
2. When you need to look at the implementing class, it can take a lot of work to find it.

According to SOLID, "one should “Depend upon Abstractions. Do not depend upon concretions.” "

The citation says: “, as much as is feasible, the principle should be followed. The reason is simple, concrete things change alot, abstract things change much less frequently. Morevoer, abstractions are “hinge points”, they represent the places where the design can bend or be extended, without themselves being modified (OCP).”

I don’t see that all or even most concrete things change a lot (at least in their public interface). If the public interface needs to change then doesn’t that mean that the interface class probably would need to change also?

How would that work with a Swing program? Would all GUI elements need to be passed in as interfaces?

Can documentation be a "bad smell"?

How much code documentation is a symptom of bad coding (i.e. poor method or variables names, poor class or package structure, missing logging, etc)?

Management: Enemy of Enterprise - Doug French - Mises Daily

Management: Enemy of Enterprise - Doug French - Mises Daily: "Once you have the business going, interruptions must be avoided; they are productivity killers, as are meetings. Get some sleep, get some quick wins and remember that good enough is fine and nobody can estimate worth a darn."

Crowd-Sourced Call Identification and Suppression | FTC Robocall Challenge

Crowd-Sourced Call Identification and Suppression | FTC Robocall Challenge: "We recommend the creation of a system that allows users to report, to an online database system, the originating telephone number of unwanted solicitations, advertisements or robotically placed calls (henceforth called “spammers”). We also recommend that users’ telephones or external hardware may automatically query the database about the telephone number of an incoming call (before the call is answered, or even before the telephone rings) to determine if the caller has been flagged as a spammer by other users, and optionally block the call or otherwise handle it differently from a non-spam call."

Titles are Toxic: Rands In Repose

Titles are Toxic: Rands In Repose: "never in my life have I ever stared at a fancy title and immediately understood the person’s value"

"The main problem with systems of titles is that people are erratic, chaotic messes who learn at different paces and in different ways. They can be good at or terrible at completely different things, even while doing more or less the same job. A title has no business attempting to capture the seemingly infinite ways by which individuals evolve. They are imprecise frameworks used to measure the masses. To allow leadership to bucket individuals into convenient chunks so they can award compensation and measure seniority while also serving as labels that are somehow expected to give us an idea about expected ability. This is an impossibly tall order and at the root of title toxicity."

"Titles, I believe, are an artifact of the same age that gave us business cards and resumes. They came from a time when information was scarce. When there was no other way to discover who you were other than what you shared via a resume. Where the title of Senior Software Engineer was intended to define your entire career to date."

Estimation

PurposeOfEstimation: "For me, estimation is valuable when it helps you make a significant decision." i.e. "allocation of resources" or "to help with coordination"

"So whenever you're thinking of asking for an estimate, you should always clarify what decision that estimate is informing. If you can't find one, or the decision isn't very significant, then that's a signal that an estimate is wasteful. When you do find a decision then knowing it focuses the estimate because the decision provides context. It should also clarify the desired precision and accuracy."

"I once remember a gnarly project manager say that plans and estmates were like a lettuce, good for a couple of days, rather wilty after a week, and unrecognizable after a couple of months."

An Appropriate Use of Metrics

An Appropriate Use of Metrics: "Project management reinforces this perception by asking the question, "How many stories did we finish coding this week?" instead of the better question, "How many stories are we happy to release to end users?" or better yet, "How many stories did we release to end users?" An even better question is, "How much value have our users found from our recent releases?" "

"Use the following guidelines to lead you to a more appropriate use of metrics:

Explicitly link metrics to goals

Favor tracking trends over absolute numbers

Use shorter tracking periods

Change metrics when they stop driving change"

"The lines between the measure chosen to monitor progress towards the goal and the actual goal itself blur. Over time, the reason behind the measure is lost and people focus on meeting the target even if that metric is no longer relevant. A more appropriate use of metrics is to ensure that the chosen measure for progress, the metric, is teased out, yet related to its purpose, the goal."

"It is easy to monitor activity (how much time they sit at their computer) yet it is hard to observe the value they produce (useful software that meets a real need). "

"There may be significant difference between code coverage of 5% and 95%, but is there really a significant difference between 94% and 95%? Choosing 95% as a target helps people understand when to stop, but if it requires an order of magnitude of effort getting that last 1%, is it really worth it? "

"Looking at trends provides more interesting information than whether or not a target is met. Working out if a goal is met is easy. The difficult work, and one that management must work with people with the skills to complete is looking at trends to see if they are moving in the desired direction and a fast enough rate. Trends provide leading indicators into the performance that emerges from organizational complexity. It is clearly pointless focusing on the gap in a number when a trend moves further and further away from a desired state."

LinkedIn CEO: Site will become 'economic graph' over next decade | Internet & Media - CNET News

LinkedIn CEO: Site will become 'economic graph' over next decade | Internet & Media - CNET News: "Weiner envisions companies using LinkedIn to evaluate a workforce in an area to see if it's equipped with the skills to get the jobs that will be emerging."

Source Control Message for Single File Add

What should be in a source control commit message for a single file add?

1. Reason: The reason for the file should be in a comment in a file so it would be a duplicate to also include in the commit message.
2. File add: Already part of the commit
3. Issue identifier

Laws are like computer programs

Laws are like computer programs. Like programs, laws try to apply rules to change their environment but the system for making laws isn't setup to make good laws. Programmers have generally accepted best practices to increase the chance of good code but there aren't such practices for laws (or they are minimal).

1. Laws have to deal with much more varied input than computer programs.
2. Laws have greater risks when the input isn't handle correctly (people can die)
3. Laws are written by people who are selected for their ability to have general goals -- not people who are necessarily good at ensuring that all of the details are correct. Generally visionaries don't write code.
4. Laws have virtually no testing that is done before implementation (sometimes there are studies but they are usually general). Code generally has multiple types of testing: compiler, unit, functional, QA, user, etc that verify that the code is good before it is released.
5. Laws are written by large groups that are all responsible for large portions. Programmers are usually responsible for small portions that don't overlap much.
6. Laws are applied to large groups before being tested on small groups (sometimes federal laws are based on state laws but that is rare and loose).
7. All of the people who help produce programs generally focus on a narrow domain but laws are mainly written by generalists (exceptions being lobbyists and "experts")
8. Laws reference parts of laws, which is like functions
9. Simplicity isn't a goal for laws.
10. Laws use the waterfall model
11. Laws don't have official comments

What other programming best practices do laws not follow? Are there programming practices that laws follow well?

Help wanted: $183K plus. Tool gives lowdown on tech salaries | Bootstrap - CNET News

Help wanted: $183K plus. Tool gives lowdown on tech salaries | Bootstrap - CNET News: "interactive tool (see below) that let's you see what tech jobs pay among private firms across the country."

Code can't be stolen under federal law, court rules | Security & Privacy - CNET News

Code can't be stolen under federal law, court rules | Security & Privacy - CNET News: "The enormous profits the system yielded for Goldman depended on no one else having it," Jacobs ruled. "Because [the high-frequency trading system] was not designed to enter or pass in commerce, or to make something that does, Aleynikov's theft of source code relating to that system was not an offense under the EEA."

Is it more secure to allow the browser to save a website password or prohibit it?

Is it more secure to allow the browser to save a website password or prohibit the browser from saving the password?

Benefits of allow the browser to save the password:

1. Spoof websites are more easily detected because the username and password don't show up (this may be a mute point if the username is saved but not the password).
2. Keyloggers won't pick up the password if you don't type it. (Thanks to Thrawn)
3. People will be less likely to keep the password in an obvious place (i.e. sticky note)

Benefits of prohibiting the browser from saving the password:

1. Stops someone with access to your computer from accessing the passwords (the level of access needed can vary based on how the passwords are stored).

The value of low-level logging

All of the info in logs can be obtained through a debugger, if you can reproduce the problem. Low-level logging allows a devloper to debug a problem without the work of reproducing the problem - Q.A. or another developer can just send the debug log for review. When it is difficult to reproduce a problem, debug logs can be invaluable. Debug logs also give a wealth of information without having to choose that info beforehand. While debugging a developer may find that more information is needed and it can require re-running the test to get that information.

How Trello is different - Joel on Software

How Trello is different - Joel on Software: 'A feature that you built and tested, but didn’t deliver yet because you’re waiting for the next major release, becomes inventory. Inventory is dead weight: money you spent that’s just wasting away without earning you anything.'