Category Archives: Communication

Soft Skills: The Software Developer’s Life Manual – A Review [Audiobook]

I’m almost through the book Soft Skills: The Software Developer’s Life Manual. I’m listening to the audio-book.  I like it, it’s pretty good. Along with the benefit of having the author, John Sonmez narrate his own book, he also provides a lot of commentary, discussion, and elaboration.  At first I thought it was annoying that the author would go off on a tangent every once in a while, then say “back to the book” and continue the verbatim reading.

However later I realized that the commentary and discussion were worth the tangents.  There are several very valuable tid-bits of information in this book, such as references and discussion of Pomodoro Technique, and KanbanFlow. The book touches a very broad scope of topics, from software development methodologies to personal finance management tips.  The book tries to help it’s readers see the habits and actions (or lack thereof) that are required to achieve a high degree of quality, consistency and professionalism in your career.

One of the things to keep in mind is that this book discusses a lot of tools and techniques that are documented external to the book itself.  The author frequently references his company’s website where the reader can find more information.

This book and the topics it discusses are very relevant to the success of an aspiring software developer.  Worth a read!

Expressing Your Authority May Be Working Against You

It doesn’t matter whether you are a senior engineer, a team lead, or an IT manager – eventually you will encounter the situation.  A meeting or discussion that becomes slightly more animated than usual.  Opinions are strong, and it is clear that consensus will not be found on this particular contentious issue today.   As a senior engineer, team lead, or manager, it is fair and understood that sometimes you will have to make a call one way or the other.   This article is not about whether or not you should make that call.  This article is about how to make that call.

Lets say for example that you are in a meeting with many of your direct reports, and these direct reports may be working on different aspects of the same project – or – they may be on different teams, still working toward the successful completion of a specific project.  There is a contentious concern, perhaps on the complexity around a specific problem where dead-lines need to be set.  Opinions are being vocalized, and the volumes of those voices are getting louder.  There doesn’t seem to be a clear way to reason out the differences of opinion at the moment. People are being blamed, fingers are being pointed.  You are the team lead/manager.  What do you do?

Well, lets look at what you should not do, with some suggestions on how you might handle these situations differently:

  1. Do Not Swear
    • It may seem to you that swearing at a meeting to get the attention of your team is either hip, cool, contemporary, or resonant with authority, but you would be dead wrong.
    • Anyone who really wants to succeed, and wants their teams and their company to succeed, will always want to bring positivity to the table.  By swearing (and I mean anything that is obviously vulgar, saying something like “what the fuck”), you are tarnishing the respect that your direct reports may have had for you.
    • With you being in a senior position, your direct reports look up to you, and will often try to mimic your mannerisms and the method by which you work (without full context of course), and they will replicate these mannerisms upon interactions with other teams and team members.
    • If you are swearing because you are highly frustrated, and simply lost control, then that is another matter that you need to address, immediately.
    • Apologize – If you do swear, communicate to your team that you are indeed frustrated, and did not mean to offend anyone.  Apologize sincerely to the whole team, and this will immediately re-gain any respect you may have lost, since you are showing the team that you are responsible for your actions, and are willing to concede when you’ve made a mistake.  This takes courage, and is a great example to set for your team.
  2. Do Not Raise Your Voice
    • There are many situations where raising your voice might be appropriate, for example to get everyone’s attention so that a meeting can begin.  Context is very important.
    • However, raising your voice for the sake of making a point (or to invalidate a point being made by someone else), or to express your authority will only back-fire, as you will lose the respect of those to whom you are trying to make your point.
    • Silence is golden – if you need to visibly show your disappointment or disagreement with an individual or a decision being made at a meeting, then the best thing to do is to be quiet.  Stand up, and hold your hand out as if you are pushing something away from you (think Neo in the Matrix).  Make it visible that you have something to say, or that you disagree, or would like to take the discussion off-line.  Your teams will respect you even more if you are able to command the attention of a room with silence.  Any fool can get attention by being loud and abrasive.
    • Again, by raising your voice, you are setting an example for others to do the same as well.  Your team members will take your queue and start to build a paradigm around how they see you acting and reacting, and they will do the same – believing either that this is what it takes to be successful, or that this is how YOU would rather interact.  They may even raise their voice against you in the very same meeting, with the misguided belief that you would see this as a positive characteristic in them.  Do not perpetuate this line of thinking.  If you are able to command a room with silence, then everyone else will follow suit and become silent, at which point a real and valuable conversation can once again be had.
  3. Do Not Perpetuate Fact-less Finger-pointing
    • Just because someone on your team makes a claim against another, doesn’t mean it is true.  If one team member claims that they are in a bad situation, or that they “are blocked” by another team or individual, do not simply jump on that finger-pointing train.  This is the equivalent of joining a pitch-fork mob against a monster which you didn’t know existed only a few minutes ago.  As a leader, you should be critical of all information coming your way, especially the hearsay that tends to happen when a second party is criticising a third.  It is a purely reactive method of dealing with people and situations, and it does more harm than good.
    • Ask questions – but from the perspective of information-gathering, not finger pointing.  What this means is that you are taking ‘people’ out of the picture, and instead are looking at ‘facts’ (current status and configuration, time-stamps, and corroborating evidence).  Instead of just taking those who claim that the ‘sky is falling’ at their word.
    • If you are going to address someone who is to be the defendant of a particular criticism, don’t ask them “Did you do (or not do) x?”.  Instead of being open about the obstacles which have prevented them from completing a certain task, this puts people on the defensive.  Try instead to be on their side.  If you are sincerely interested in achieving success for all teams, and for the entire company, and not just for yourself or your team, then show this by being helpful.  Instead, make statements like “What can I do to help move x along?”, or “Can we spend a few moments to break down this objective into smaller tasks?  Perhaps I or someone from my team can assist with moving this along?”.  This kind questioning puts the person being criticised in a position to ask for, and accept help if they need it.  If it is simply a matter of prioritization, something the person hadn’t gotten around to just yet, or if they simply lost sight of the tasks – they will once again be aware that the task needs attention.  They may even be embarrassed that you are offering to assist them with such a simple task that they will openly concede that they’ve simply lost sight of it, and would likely resolve the situation right away to avoid further embarrassment.
    • Bring people together.  Be an example to the person raising the issue or making the criticism by bringing together the parties involved so that there can be a quick and constructive dialogue about current obstacles or perceived road-blocks.  Show people how to solve problems without escalation, so that they can perpetuate a positive methodology around people-handling, and so that they themselves can become positive role-models that others can aspire to.
    • If you instead believe that perpetuating unfounded criticism and finger-pointing is a good thing, and that is all you believe you can or should do; then all you will end up doing is to make people feel alienated.  Those who are being criticised will go on the defensive, and they will likely want to avoid interacting with you (or anyone else on the finger-pointing bandwagon) going forward.  This does nothing to improve collaboration within or between teams.  Your organization and your company will suffer because of it.

Getting upset at your direct reports, raising your voice in order to re-claim a conversation, or simply ignoring input from specific people is a sure-fire way to diminish your reputation and earned respect across your entire team.  For the most part, private sector IT including software development, systems administration, and project management, is all thought-work.  It is important to be aware of and to understand how much psychology plays a part in the success of a team or organization.  Positivity breeds positivity, and the inverse is true as well.

Managing Your SMTP Relay With Postfix – Correctly Rejecting Mail for Non-local Users

Image result for SMTP postfix

I manage a few personal mail relays that I use for relaying my own mail and for experimentation purposes (mail logs are a great source of unique and continuously flowing data that can you use to try out different ideas in GUI, database, or parser development).  One of them was acting up recently.  I got a message from my upstream mail-queue host saying that they’ve queued up quite a bit of mail for me over the last few weeks, and that I should investigate, as they do want to avoid purging the queue of valid mail.

Clearly I wanted to avoid queuing up mail on a remote server that is intended for my domain, and so I set out about understanding the problem.

What I found was that there was a setting in my /etc/postfix/main.cf that, although it was technically a valid setting, was incorrect for the role that mail-server was playing.  Specifically the mail server was supposed to be rejecting email completely for non-local users, instead of just deferring it with a “try again later” message.

In this case, I’m using Postfix v2.5.5. The settings that control this configuration in /etc/postfix/main.cf are as follows:

  • unknown_local_recipient_reject_code
  • local_recipient_maps

local_recipient_maps

local_receipient_maps defines the accounts that this mail server will accept and relay mail for. All other accounts would be “rejected” by the mail server.

However, how rejected mail is treated by Postfix depends on how it is configured, and this was the problem with this particular server.

For Postfix, it is possible to mark a message as “rejected”, but actually have it mean “rejected right now, but maybe not permanently, so try again later”. This “try again later” will cause the e-mail message to be queued on the upstream server, until it reaches some kind of retry time-out and delivery is once again attempted. Of course this will fail again, and again.

This kind of configuration is great for testing purposes, because it allows you to test the same messages over and over again without losing them, or to queue them up so that they can be reviewed to ensure they are indeed invalid e-mail messages. However this is not the state you want your mail server to be in permanently. At some point once things are ready for long-term (production) use, you want your mail server to actually reject messages permanently.

unknown_local_recipient_reject_code

That is where unknown_local_recipient_reject_code comes in. This configuration property controls what the server means when it “rejects” a message. Does it mean right now, or permanently?

The SMTP server response code to reject mail permanently is 550, and the code to reject mail only temporarily is 450.

Here is how you would configure Postfix to reject mail only temporarily:

unknown_local_recipient_reject_code = 450

And here is how you set Postfix to reject mail permanently:

unknown_local_recipient_reject_code = 550

In my case, changing the unknown_local_recipient_reject_code from 450 to 550 is what solved the problem.

In summary, if you ever run into an issue with your Postfix mail server where you believe mail is set to be REJECTED but it still seems to be queuing up on your up-stream mail relay, double-check the unknown_local_recipient_reject_code.

# Local recipients defined by local unix accounts and aliases only
local_recipient_maps = proxy:unix:passwd.byname $alias_maps

# 450 (try again later), 550 (reject mail)
unknown_local_recipient_reject_code = 550

References
http://www.postfix.org/LOCAL_RECIPIENT_README.html
http://www.postfix.org/postconf.5.html#unknown_local_recipient_reject_code

Maybe Big Brother Isn’t As Bad as You Think..

Cross-post from LinkedIn, in response to Maybe Big Brother Isn’t As Bad as You Think:

“This is a future Orwell could not have predicted. And Big Brother may turn out to be a pretty nice guy.” I respectfully disagree. As others have noted, there is (and always will be) a huge asymmetry in the information being shared and consumed as far as “Big Brother” and state surveillance is concerned. The “sharing” in this case is one-way. Only those in power would have the ability to view and make sense of the data.

Your argument that we “choose to share data” because we get something in return, is flawed. Most people do not choose to share the kind of data that we are referring to in this regard, otherwise it would be done freely and intentionally, and the secretive information gathering we are witnessing here would not be taking place. Even the information we do share “intentionally”, is done so for the most part by many of us who do not pay attention to, and truly consider the ramifications of the many disclaimers, license agreements, and privacy policies that we agree to on a daily basis. What we get in return, as you suggest, is far from a fair compromise.

This one-way “sharing” means that those who are in power have not only the ability to collect this information, but also the tools and the ability to analyse this data and generate statistics that the rest of us have no choice but to consume as facts. Aside from the ability to collect and “make sense of” the data, on our behalf – those in power also have the ability to limit and restrict infrastructure and resources in order to manipulate the “facts” at the source. For example, the ability to manipulate DNS or shut down ISPs to prevent the dissemination of data – effective censorship. Many people have been detained or persecuted (or worse) simply for “sharing” their thoughts and beliefs.

How can you make an anti-Orwellian argument, a case *for* “Big Brother”, and suggest that this kind of sharing can be good and benefit us all equally, when the vast amount of information we are talking about can be controlled from source to audience by such small percentage of the population? I suggest you pay attention the thoughts and many works of notable individuals such as Noam Chomsky, Glen Greenwald, and Lawrence Lessig, and perhaps reconsider your position on this matter. I am currently reading Greenwald’s latest book “With Liberty and Justice for Some: How the Law Is Used to Destroy Equality and Protect the Powerful”. I am sure you would find it most enlightening.

For those more visually/audibly inclined: “Noam Chomsky & Glenn Greenwald – With Liberty and Justice For Some”

httpv://www.youtube.com/watch?v=v1nlRFbZvXI

Why You Shouldn’t be Sharing “Live” Documents by E-mail

 

If you and your team, in 2013, are still sharing Microsoft Office (Word, Excel) documents via internal corporate e-mail, I’ve got news for you.  You’re doing it wrong.

“Live documents” are documents that are actively being updated and collaborated on by multiple people.  Collaborating on these documents by e-mail is a process that you should avoid.  It is a process that can eat away at your team’s productivity precious minutes at a time, and can severely impede your team’s work-flow and ability to stay synchronised.

I’ve been involved with projects where this method of collaboration was adopted.  Whenever I recognize this to be the case, I would immediately share my concerns, and try to suggest better ways of getting the team organized. There are always better ways to do it.

One of the biggest problems with e-mail document sharing is that there is no tracking or accountability.  There is no way to easily know what version of the document you have in your possession.  Is it the latest?  Perhaps it’s new enough?  Ever had to find an email with a document attachment, and ended up trying to craft clever little search terms to search your inbox?  Even if you find the document you were looking for, there is no way for you to know whether it is the last official revision, unless a system is implemented to allow “official” versions of the document to reside in a central location.

If there is a point-person in charge of managing this kind of set-up (for example, a simple system implemented with shared folders), and the maintainer ends up leaving the company for any reason (vacation, short-term disability, lay-off), then you still end up in a bad situation.  Without someone actively maintaining the structure of the document store, things will end up getting messy very quickly.  Users will begin storing documents in arbitrary locations (whatever feels right at the time), and before you know it, you will have to start yet another document archive clean-up project.

Version control is ubiquitous, and it is here to stay.  Any company (in any industry, not just IT) not seriously considering a process for document revision control should at least make it a point to have the discussion at least once a year.  You may find that your current document handling processes are actually a significant time waster, and that implementing a document management system could save you a lot of time (or money) over the long run.

There are many document sharing and collaboration technologies available today.  Some of the more popular include Sharepoint (if you are a Microsoft shop) or Documentum.  There are also many open source (free) packages, such as Drupal, Joomla, and Liferay.  There are even projects like Etherpad that make collaboration just plain fun.  You can also roll-your-own (if you are so inclined) by developing a custom system on top of foundational version control software such as Git or Bazaar, as I personally have done in the past.

Do your research when considering a content management system.  Some important considerations you might want to make include:

  • Is it easy to set up?
  • Is it easy to use?  Does it blend well with our team’s work-flow?
  • Is it safe?  Is it easy to make backups?
  • What kind of security mechanisms does it have built-in?
  • Is it easy to get our data out of the system (strong import/export functionality), in the event that we decide to move to another system in the future?
  • Is it cross-platform, or does it tie us to a specific platform (operating system)?
  • Is the cost worth the investment for a company our size?

The important thing here is to start thinking about it.  Be open to evaluating multiple products before you decide on a system that blends best with your organization’s work-flow. Software is about solving problems, which includes eliminating routine and time-consuming tasks.  If your company is not continually looking at new ways to improve efficiencies via clever (and practical) software implementations, then it will eventually be left in the dust as more efficient start-ups and entrepreneurs bring their shiny new productivity platforms to the game.

Team Meetings at the Workplace

I’ve been to many team meetings (or “all hands”) that have, in the end, provided no real value to the team in attendance.  It is very possible (and likely quite common) that most meetings are actually a waste of time (as many of my closest colleagues and friends would agree).  However, this does not always have to be the case.

Meetings are important to have.  They provide an opportunity for team members to share not just the facts, but also how they feel about the current situation for a given project.  Team meetings can often provide context for the day-to-day work that each of us is involved with.  Just as importantly, it is an opportunity for leaders to maintain an awareness of how their team members are feeling, in order to better estimate how the team might respond given additional stress.

Meetings have to be run with intention in order to be successful.  Topics should be specific, and every topic discussion should end with an actionable deliverable assigned to a specific individual.  This may sound a bit restricting, but it goes a long way toward saving your team more time for actual work, along with giving them (and yourself) more time to relax.

There are many meetings that I have attended where discussions were essentially a one-way dialogue between the presenter and the rest of the team, where feedback was neither elicited nor volunteered.  When the host (usually a team lead, manager, or PM) asks the ever gripping question “..any questions or comments on this?”, and a conference call of about twenty or so people falls dead-silent.. well, I would consider that a problem.

Often the problem is that the meeting is too broad, involving too many people who don’t work with each other on a regular day-to-day basis.  Smaller meetings are the key to success.  Meetings should be specific, covering 3-5 of the most important items or active projects.  Meetings should also be quick (standing meetings are often very effective).  Questions and responses should be clear and to the point.  “What’s the status of the X project?”   “What’s changed from last week?”  “What do you need to keep this on track?”

Team meetings shouldn’t get too technical either.  That’s what e-mail, white-boards, and dedicated meetings are for.  Having technical discussions at team meetings will rarely be beneficial, and will often just turn into an echo chamber or a religious debate.  These types of discussions are good to have, but not when leadership is at the table.

When leadership is at the table (Managers, Sr. Managers, Directors),  the focus of the meeting should be for the leadership team to identify the most critical issues to address, and do all that is necessary to raise the collective spirit of the team; with feedback that is directly related to the work that they are doing.  The only way to do this is to be aware of the team’s accomplishments since the last meeting.  Every little inch matters.  Every little unit of work and motivation you can squeeze out of your team will benefit your project, and your stakeholders.   I am not suggesting micro-management, nor am I advocating unnecessarily cracking the whip.  Instead, what I would suggest is that teams work together to develop processes and routines that will continually provide positive, targeted feedback on the work that the staff has accomplished.

 

People Getting Along

It always surprises me when people share a bit more about themselves than they realize, especially those who think themselves fairly reserved, quiet, or “better than thou”.

I find this occurs when a big change has happened (or is happening) in that person’s life; a life-changing change. Sometimes these are the only moments when you get any kind of real insight into how that person thinks and reacts under pressure, or how they truly feel about the people and the issues in the world around them.

People Aren’t Smart Enough for Democracy to Flourish, Scientists Say

It’s occurred to me fairly often of the past several years that the reason why democracy doesn’t achieve ideal results is simply because most voters are ill-informed about the real issues facing the world; and not just the issues being relayed via cable television news networks.  This article simply confirms my assumptions.. unfortunately.

For example, if people lack expertise on tax reform, it is very difficult for them to identify the candidates who are actual experts. They simply lack the mental tools needed to make meaningful judgments.

Nagel concluded that democracies rarely or never elect the best leaders. Their advantage over dictatorships or other forms of government is merely that they “effectively prevent lower-than-average candidates from becoming leaders.”

Read the full article here –>>

TEDxUW – Larry Smith – Why you will fail to have a great career

Larry Smith, economics instructor at the University of Waterloo, gives a very moving lecture to both educate and inspire upcoming graduates on the reason why most of them will fail to have a great career.  He doesn’t come right out and say it, but he does all he can to point his viewers in the direction of the answer in the hope that his audience will come to the realization themselves.

httpv://www.youtube.com/watch?v=iKHTawgyKWQ

 

UK Government To Demand Data On Every Call And Email

[techweekeurope.co.uk] UK Government To Demand Data On Every Call And Email

Plans could force ISPs and phone operators to hand over records on all phone calls, emails, Tweets and Facebook messages

[telegraph.co.uk] Phone and email records to be stored in new spy plan

Details of every phone call and text message, email traffic and websites visited online are to be stored in a series of vast databases under new Government anti-terror plans.

This story also made the Slashdot front page.