Tue, 03 Dec 2024 09:32:02 -0800WeeblyTue, 17 Feb 2015 22:59:19 GMThttp://markhack.com/blog/soft-skillsIt is interesting to see how companies value and evaluate skills.

Soft skills i.e. everything non-technical include:

• Timeliness of deliveries
• Perseverance
• Attitudes to failure
• Prioritizing amongst multiple items
• Taking the initiative
• Coaching

Most under-performance is due to the lack of soft skills and these are the most difficult to evaluate in an interview and to teach and are rarely included in job descriptions or training.

]]>Sat, 31 May 2014 20:46:08 GMThttp://markhack.com/blog/confusing-the-symptom-with-the-problemPick the process improvement process you prefer and there will always be an analysis phase specified before deciding what to improve.

For this entry, I am going to focus on the postmortem or 'lessons learned' which should be done after any project or iteration and the interesting reasons why the analysis rarely leads to any change.

When gathering the good, the bad and the ugly, there seems to be a natural propensity to state the symptom and not the problem. Gather the symptoms and spend the time analyzing which are just symptoms and spending the time doing the analysis to uncover the problem. Some symptoms do need to be addressed, but once they are do not ignore them especially when they are an indication of a problem.

Avoiding the analysis ( the hard part) rarely leads to any meaningful improvement so focus on uncovering,understanding and addressing the problem and do not just list and address the symptom.

Aspirin is wonderful for a headache but not very effective if the problem is a brain tumor !

]]>Fri, 28 Feb 2014 01:00:10 GMThttp://markhack.com/blog/february-27th-2014When you read this article, please recognize that this is not a statement on culling and if you do feel a need to express your views on this topic, that there are many forums where you may do so.

With the standard caveat that I am not a sociologist or knowledgeable on wildlife management, here goes ...

If we can extend this to the present policies in companies where the older/more experienced personnel are "culled" when cost savings measures are instituted, we should all be concerned over the outcome of the loss of discipline and life training.

From http://www.elephantsforever.co.za/elephant-culling.html#.Uw_avPFl7tc

In South Africa, when herds were culled, the adult animals were selected with the following consequences and recommendations:

In the case of elephants, it is recommended that entire herds be culled at once. This prevents orphaned juveniles and grieving parents. However, the park or farm frequently chooses to cull the adults of the herd, and then sell the orphans to zoos or circuses. While the farmer benefits financially, this leads to a generation that has not benefited from the discipline and important life training that they would ordinarily receive from their elders. Without this discipline, this generation becomes unruly and even dangerous, often displaying unpredictable behavior towards humans and other animals.

Enough said for today. ]]>Sun, 16 Feb 2014 01:07:25 GMThttp://markhack.com/blog/marksimsI am infamous for one liners which are interesting, fairly serious and somewhat humorous at the same time which have been dubbed 'Marksisms' (thanks to John Watzke for this).

Marksism: A practical one liner which has a lot of truth.

I will use this page to collect Marksisms and periodically add a few more

• I would rather explain once why you are late than several times why you are bad.
• The best way to think outside the box is to avoid putting the box on your head in the first place.

• There is no such thing as quick and dirty - just dirty
• Process is what you are told to do, practice is what you really do.
• The best process is the one which works
• The difference between visibility and exposure is that you never die from visibility.
  

]]>Wed, 22 Jan 2014 10:54:01 GMThttp://markhack.com/blog/privacy-concerns-historical-perspectiveAfter the Snowden storm, I thought this article may give an interesting historical perspective on privacy.

Sacramento Daily Union, Vol 2, # 119 11 July 1876

THE PROTECTION OF THE TELEGRAPH.

Congress is making serious trouble for Itself and the country by its arbitrary and high handed proceedings regarding the telegraph. There is no justification whatever tor the manner in which old dispatches have been demanded, and telegraphic superintendents have been compelled to produce copies of private dispatches.

The vital principle of the telegraph is privacy, and if it does not possess this at least on equal terms with the mails, it will rapidly fall into disuse. Congress has no more right to demand the surrender of copies of private dispatches than it has to open letters passing through the mails, or to call upon accused persons and their friends to produce their private correspondence. It is not only Congress, however, that has lately infringed upon the inviolabilty of the telegraph. It came out recently that the Atlantic and Pacific Telegraph Company had sold a great many old dispatches to a junk shop for waste paper, and a House Committee secured the entire heap. It is of course im possible to tell what secrets may not be concealed among those dispatches, and under the hands of a Democratic Committee aided by a regiment of sensational correspondents, it can hardly be hoped that any reputation would be spared, suspicious facts concerning which might be discovered.

The action ot President Eckert, of the Atlantic and Pacific Telegraph Company, in permitting the old telegrams to go to the junk shop is inexcusable, and suggests the desirability of an inquiry as to what becomes of all old dispatches. The Western Union Company we believe preserve their copies two years, but how they are disposed of at the expiration of that period we do not know. It is clear, however, that the telegraph should be protected, and that the course of these Paul Pry Committees in demanding dispatches is altogether unwarrantable, and a dangerous invasion of private rights which must not pass unrebuked.


Source:  California Digital Newspaper Collection, Center for Bibliographic Studies and Research, University of California, Riverside, http://cdnc.ucr.edu]]>Mon, 13 Jan 2014 11:49:18 GMThttp://markhack.com/blog/what-engineers-never-tell-managementThe link below is an  survey which should be required reading for all middle and upper managers in engineering companies:

http://electronicdesign.com/trends-amp-analysis/2013-engineering-salary-survey-pressure-salaries-down

It contains a large number of divergent opinions, but states most of tone which I have noted amongst engineers, and says most of the things they would be very unlikely to transmit to management.

Since this is a long article, I will not be commenting on it except to say that it does allude to a multitude of complex problems which we should all be thinking about and addressing.

Hope this provokes as much thought for you as it is doing for me.

]]>Mon, 09 Dec 2013 21:29:16 GMThttp://markhack.com/blog/mentoringA few days ago I saw an interesting article on personnel evaluation where the author noted that a packet of seeds does not carry a picture of the seeds but rather the plant that they will become with nurturing. This appears to be the best way of viewing the role of the mentor - recognize and nurture the potential of the mentee.

Most of the mentors I have had took the approach of sink or swim, and luckily I swam.  However, when you act as a mentor, I believe your main task is to see the potential, understand what is needed to achieve that potential and assist in growth by a mixture of preparing the person/environment as well as some showing by personal behavior and motivation. Like your garden this takes an ongoing investment to see the results.

Growing the seed is more than planting and occasional watering !]]>Sun, 24 Nov 2013 14:51:18 GMThttp://markhack.com/blog/programmer-productivity-metricsAll of the process improvement processes are a variation on:

• Define
• Measure
• Analyze
• Act
• Control

So to improve, one must measure and one of the most requested and hotly debated metrics is programmer productivity, which is used for ratings, raises and a plethora of non-process activities.

Unfortunately, this measurement is often subject to inversion ( does not correlate well to what is being measured) and when people realize that it is being used for rating, can and will be gamed. The other unfortunate reality is the programmer productivity is actually a better measurement of the process than of the people, so it is a very useful metric if used correctly.

As always, be careful what you measure since this will often be counterproductive and drive unintended consequences as can be seen in the much quoted Dilbert cartoon -
http://dilbert.com/strips/comic/1995-11-13/

In conclusion, ensure that metrics are judiciously used and that productivity and performance are based on more than one metric



]]>Fri, 22 Nov 2013 14:29:29 GMThttp://markhack.com/blog/the-old-is-new-again-nosqlWith all the buzz over noSQL, I installed one a few weeks ago, ran a few examples and smiled a lot since we are now back to hierarchical, non normalized databases.

Many years ago, when I was working in the systems division of a large banking organization, we got constant pressure to move all the databases to a 'more modern SQL database. We resisted this since, besides the migration cost, the performance impacts would have been unbearable. The same justification of high transaction rates on large databases is the reason that noSQL is being touted as the solution.

However, people seem to have forgotten what the push was to move to SQL in the first place, and are at risk of repeating past mistakes. Go and search for CODASYL and all the debates which raged over hierarchical versus relational databases and the pluses and minuses of each of the technologies and you will see that the conversations are not all that different.

Each approach has its place and the key is always using the solution that best fits the problem and not bending the problem to fit the solution.

Since each noSQL implementation I looked at has its own API, if you are going down the noSQL path, (and I do not like pre-emptive coding) at least encapsulate the data accesses so if you decide to move to a different infrastructure, that the cost of moving is limited.


]]>Sun, 27 Oct 2013 09:59:18 GMThttp://markhack.com/blog/simplifiers-and-complicatorsThere are two types of people, simplifiers and complicators and there are generally more complicators than simplifiers especially in software. If this were not true, we would not have the joke that "if it ain't broke, it doesn't have enough features yet".

Complicators can take any problem and complicate it, they can add irrelevant facts, take hours of every bodies time, and unfortunately, since they are visibly in the thick of things, are usually getting accolades and rewards.

Simplifiers can separate the important from the irrelevant and are those quietly getting the job done, not because the problem was simple, but because they made it so.

Simplifying creates a more focused, productive and profitable environment, so constantly check that things are being kept as simple as possible, and if anything feels overly complex, go back and think about it more before rushing off to execute.

Here are some steps to assist in simplification:

• Reward the behavior you want - you tend to get what you ask for.
• Plans should be simple, short, clear and communicated.
• Ensure that priorities are set - if everything is important, nothing is.
• Create an environment where review and correction is the norm.
• Avoid analysis paralysis - understand that data is never complete and less is better.

]]>