techfogies

[techfogies]

Risk versus Reward -  Volunteering or Initiative?

Has your boss mentioned that you don't seem to be showing initiative? Do you wonder if you should volunteer for tasks or projects so you can get a raise or a promotion? You should carefully examine the risks along with the rewards before making your decision.

The rewards include (in roughly increasing goodness): resume accomplishments, intangible recognition (your management chain hears about it and remembers you), official recognition (a certificate, plaque, announcement in a company-wide email or newsletter, or other tangible reward like a gift card), stock options, bonuses, raises, and promotions.

If your organization has a good track record of providing these rewards, then that is a reason to show initiative or volunteer. If you have management that provides constant feedback, that's even better (you can get a clearer idea of how close you are to these "power-ups").

However, even if your company has a good track record, how good is your relationship with your management chain? If it's not good, then your efforts might go deliberately unnoticed or be undervalued. This is almost certainly a small minority of cases, but it can happen.

Some of the "direct" risks of taking initiative include:

Screwing up the production site or sites Adversely affecting revenue Causing downtime Causing user complaints Tripping system or applications monitors and causing internal complaints

What I call the "indirect risks" of showing initiative include: Not focusing on your other assigned tasks Wasting co-workers' time asking too many questions Failure to accomplish the task you volunteered for

Most these overlap to some degree, so you're likely to trigger multiple adverse events.

Some of the consequences might include: Bad reputation by your management chain Overt or covert "whispering campaign" by co-workers Refusal of promotions Refusal of raises Not invited or selected to participate in future interesting projects Being at or near the top of the list of candidates should there be a layoff Being fired

Given the uncertainty of receiving a reward and the potential risks and consequences, you might be thinking "why risk it?" Unfortunately, there are consequences for not volunteering or showing initiative. Those include the perception of "just doing the job" or being thought of as lazy, with the same consequences as above.

What's the best way to juggle the risk versus the reward? Everybody's particular circumstances are going to be different, but here are some questions that might help you decide.

Are the rewards actually possible? Startups may be able to offer quicker promotions or options, but may be more reluctant to offer raises. Big companies seldom offer options, but sometimes have flexibility in raises, especially if you're towards the bottom of your pay curve.

Are any of the consequences particularly in evidence? Both startups and big companies may say they "tolerate failure", but they sometimes do not practice what they preach. It is my theory that making a mistake at a startup may have more severe consequences, especially if the company is at a critical period. In a big company, you may be able to transfer to another department if you become particularly marked.

Will this negatively impact your relationship with your boss? Is your boss likely to be more unhappy with your not showing initiative or with you showing initiative but making a mistake? How about the rest of your management chain?

Can you afford to be stuck in a potential career dead-end, possibly with no managerial support, fewer or lower (or no) raises, and fewer (or no) chances at any of the rewards? If you believe your boss would be more unhappy with mistakes being made and decide not to volunteer, are you willing to stay at your job or position? You might be able to transfer to another boss, or perhaps your boss will change jobs or a re-org will happen, but what are the chances of that happening?

If the worst came to worst, can you afford to be fired?  Do you have an emergency fund or savings that can pay for 6-12 months of living expenses? Do you have a network of contacts who can help you find a job? Is your resume up to date? How about your skills?

If you're a Tech Fogey, you're probably more of the risk-averse temperament. You've had more opportunities to work for bad companies and/or bad managers, and seen what happened to too-eager colleagues. Nevertheless, I am going to cautiously recommend that you try showing initiative or volunteering. Start out small: write or edit some documentation or test and confirm a seldom-used process checklist. Small initial successes will hopefully lead to more confidence of future success.

This post was most recently updated on 8/9/2015.

[techfogies]

Store Procedures in the Cloud

If you're a developer or especially if you work in operations or system administration, you probably have a "runbook" - a collection of procedures that lists various failure modes and steps to take to recover from the condition. Hopefully it's also an ever-growing set of procedures, as each failure leads to improvements in the runbook.

If you don't have one, your first task as a TechFogey is to either start writing it, or lobby to have it done. No doubt you have ample stories of system failures and the additional unintentional damage inflicted while trying to guess what was wrong and "fixing" it.

The location of your runbook is important, though. Here's a list of places to keep it, in increasing order of "goodness".

Store it on an internal web site - this could be a Wiki of some sort, or Markdown documents or even plain old HTML. These are simple to set up, but the drawbacks are a potential for single-point failure (both network and disk) and accessibility from outside your network (especially if your VPN goes out). Store it on a filesystem - It may seem odd to rank this higher, but bear with me. There's usually only minimal version control, but you can store your document in any format you like (even Office documents). The advantage is that if you use rsync (or even just scp), you can easily keep multiple copies available on various systems in case of disk failure. You're still vulnerable to network/VPN failure. Store it in the cloud - This is the best solution. Storing it on a third-party site means you're no longer vulnerable to local network or disk failures.  There is a potential failure mode for access to the cloud service, but hold that thought for a second. You can easily restrict access so only your folks can read it. But best of all, if your vendor has a mobile app and it can keep local copies on the device, then you're no longer vulnerable to network or disk failures. Whenever you update your runbook, you can notify folks and just by accessing the document from their device, that will automatically store that version on their mobile device.

This post was most recently updated on 6/4/2015.

[techfogies]

Scripts are User Interfaces Too

Properly designed GUIs are functional and beautiful. However, a command-line script is also a user interface, and having a full stable of them is a requirement, not a luxury.

Your web application likely has an administrative interface for internal folks to maintain and operate it. Since they're not user-facting, they're often not designed well and are often neglected by the primary app developer. However, the admin app's customer, your operations staff, is just as important a customer as your users.

The trouble with GUIs is they do what they're designed to do. What this means is that they can't do anything they weren't designed to do. Did a new table get added to the schema? How about a new account status value?  Or a change in the data type of a field in a table? Better hope the admin GUI knows about it.

Not being able to do something is frustrating, but what can be worse is having to use the admin GUI to repeat an operation. Even having to do the same thing just ten times can be enough to ruin your mood.

Having command-line scripts will save your bacon. Having a script to do each type of administrative operation means you can design it to do repetitive operations. You can more easily write tests for them. And since they're calling functions that hold all the database manipulation commands (you don't have raw SQL in your webapp code, do you?), that means you're not relying on a sysadmin to not make a mistake in copy/pasting SQL from a runbook (or worse, the source code) at 4:30 am on a Sunday morning.

Writing scripts is often seen as dull or not worthy of a developer's attention. Tech Fogies know better: writing scripts is the mark of a good programmer.

This post was most recently updated on 5/21/2015.

[techfogies]

Getting Good With Graphing

Visualizing data is perhaps the best way to convince yourself or others that a problem exists or of the effectiveness of a proposed solution. Seeing a backlog going "up and to the right" is a danger sign. Seeing revenue do the same is cause for celebration.

You should take the time to learn SOME kind of graphing package, something that can take data points as input and produce a graph as output (preferably in multiple forms).  Ideally it's something that's already installed on your production systems, but if there's really nothing available, then install on your local workstation.

Where do you get the input? If what you're graphing is historical  (changes of value over time) then cron jobs (or whatever scheduling system you use) are probably the place to start. Hopefully there are existing scripts that produce the data you need: if they don't and the information is only (or most easily) available from a browser, then you'll have to scrape the HTML from the webapp (or hope there's an argument to give you better structured data in JSON or XML).

Once you have a way to periodically get the data you need, where do you store it? A good place would be a database. The specific version shouldn't matter, you just need to be able to store the time of your measurement, the actual value measured, and some kind of identifier for the data.

If you can't wrangle a separate database from your IT folks, you could again install something on your workstation, or just write to a text file (either formatted like CSV or TSV, or just plain text) somewhere in your home directory.

When it comes to actually produce the output, try to have your application do as LITTLE calculating as possible; it should just read the data and produce the graph. Instead, you should have another scheduled job that goes and pre-calculates the data that your graphing program will use.

For instance, if your application could display 7-day, 30-day, or 365-day moving averages, then leave that to the pre-calculation script. It can create new entries in the data store so that the application just needs to look up what the N-day averages are for the time period requested and generate the graph.

Finally, I'll go ahead and say it: a picture is worth a thousand words.

This post was most recently updated on 4/7/2015.

[techfogies]

Getting to Know You

If you've worked at the same company for a long time, you might find it difficult to change jobs, whether that's involuntarily or voluntarily. Many people can make new friends easily, but just as many find it difficult to adjust to a new group of strangers, especially if you had a lot of work friends at your previous company.

If your company has open workspaces, then it can be a lot harder to have a conversation with a co-worker. The open layout doesn't encourage long visits, there's very little privacy for having an intimate discussion, and some may complain about folks not from their group visiting for something other than work reasons.

Here are some suggestions for ways to try to meet your coworkers, or to strengthen an existing work relationship into a personal relationship:

<strong>Lunch</strong> - If many folks bring their lunch, try to eat in the kitchen where the fridge and microwaves are. That can encourage starting conversations about what folks brought to eat, what they like to eat, and where they like to go out to eat. If your company caters lunch (as many startups do), or most folks eat out, it can be harder as many folks tend to eat with their existing groups and it can sometimes be hard to be accepted into a group. One company provides an option whereby folks can sign up to be voluntarily mixed into a random group (once a month) that then goes out to eat. Maybe your HR or Office Manager would be interested in organizing something like this?

Gaming - Playing games with people is a great way to get to know them better. I'm talking about face-to-face games, not online gaming. Some possibilities include:

Card games - bridge or hearts are classic card games, or possibly gin rummy or cribbage. Poker is a possibility too, but you should be careful playing for money at the office. There are also plenty of specialty card games, including the collectible card games like Magic: the Gathering. Board games - there are plenty of board games, ranging from 2 players to many, including classics like Settlers of Cataan or even chess. The drawback here is that some games can take a long time to play, and some of them can be expensive to purchase. Role-Playing games - this takes more of a commitment on the players and game master, but it's a very good way to get to know your co-workers. When their characters are confronted by a horde of orcs, that's when you (if you're the game master) find out how they think.

Exercise - This can be as simple as taking a walk after lunch or in the afternoon, or it could be as strenuous as a full workout in a nearby gym. Or it could be a yoga class. If you do sweat up a storm, be considerate of your co-workers and take a shower before returning to work.

Movie Night - Hook up a laptop to a projector and you've got a quick and easy theater. If you can connect to a wall-mounted HD monitor, you'll have better sound. If you have a big enough space, you could even invite families to join in, but you should ask permission first.

There are undoubtedly other methods that can be used to break the ice and get to know your co-workers better. I invite you to comment about strategies that you've used.

This post was most recently updated on 4/23/2015.

[techfogies]

Learn What You Love

It was about three or four years ago that I realized I was stagnating technically and needed to take action. I'd generally been a book learner, but with online courses available, I tried them as well.

I discovered that the exact mode of instruction was not very important at all; I found excellent and dreadful books, and excellent and dreadful online courses. I also discovered that learning about a subject because "I thought I should", or "it may help me later", or "it'll look good on my resume" was almost always a guarantee that I wouldn't enjoy the learning experience.

What was consistent with a good learning experience (whether book or online) was that I was able to immediately combine it with a project on a subject that I enjoyed, or that had immediate work relevance. For me, that subject was gaming, both video games and role-playing games. I was able to learn a lot about JavaScript, AngularJS, Express, MongoDB, and Python in relation to games, and Node.js was relevant to my work at the time.

I won't list the bad experiences in various courses I've taken, but the one common thread is I took them for the wrong reasons.

The one exception to this rule was an online algorithms course. While neither immediately work-relevant nor related to gaming, it was a good course that helped me in technical interviews.

My takeaway was this: learn what you love, not what you think your career needs. It's okay to try anything to see if it will broaden your horizons, but I learn best when it pairs with something I love.

This post was most recently updated on 4/9/2015

[techfogies]

Group Chatting

How do you and your coworkers communicate while at work? I would say that face-to-face is always preferable, but with meetings, different work locations, and folks working at home, that's not always possible. That leaves electronic means.

Email can be useful for certain types of communication, but that tends to be used for announcements or other messages that generally want to be retained for the long term. For more ephemeral, real-time communication, the primary candidates are Instant Messages (IM), Internet Relay Chat (IRC), or group chats.

The difficulty with IM is that is generally one-to-one communication. It's hard to have a multi-way conversation with IM, and you cannot easily send your chat history to another (some would say this is a good security feature). Additionally, some IM clients do not display messages sent to you while you are not connected.

IRC has a long history as a widely used communication system, but it has drawbacks too. Although the chat room messages can be stored on the central server, you cannot always see the conversation that occurred while you were not connected (sometimes called the "scrollback"). Some IRC servers have limits on the number of chat rooms or the number of participants in a single room. And despite its long history, there doesn't seem to be a lot of active development in IRC applications.

The best of all would be a group chat application. These are almost always cloud-based, so there's no need for anyone locally to administer the system. These usually feature the ability to show you scrollback of conversations even when you were logged off. They often have smartphone apps that can notify you when you are mentioned in a channel (or page or text you if you don't have the app). They often have an API or other means to integrate with other systems (for instance, your continuous integration/build system). And they usually have a free version so you can try before you buy, although that free version usually does not have all the features of the paid version.

One thing to consider, depending on the culture of the company: you might want to have a channel where all managers are off-limits. This requires some trust, since the chat software administrator can often download the entire chat history.  If need be, set up a free version of a different chat software and only invite/allow non-managers to connect. There's still the trust issue, though.

This post was most recently updated on 3/26/2015.

[techfogies]

Dress Smartly

Dress codes seem to have gone the way of the dinosaur, although there are still some exceptions. Generally speaking, though, the days of Office Space are over.

Still, there are companies where there is an official dress code. If you work for such a company (or are in a specific role which has a dress code), then things are pretty easy: you follow the dress code. If your company doesn't have a dress code, then you might want to follow these tips:

1) Don't be the best-dressed person. There are a couple of reasons why. One is that it can be pretty expensive. Another is that you might be thought of as "copping an attititude", that is, deliberately showing off either your wealth or your styling choices. You might not intend to be arrogant, but others might think so.

2) Don't be the worst-dressed person either. Nobody likes a slob, and just like being the best-dressed person, it makes you stand out in a bad way. Others may think you don't care about the job if you can't be bothered to dress better. Managers may similarly think the same about your feelings towards the company.

3) Don't be smelly. Most of you are probably taking a shower every day, but body odor and fragrances can still be an issue. Wearing cologne, aftershave, perfume, or even using heavily scented soap could trigger an allergy attack. It's just common sense politeness to not smell.

4) Keep your hair within reason. This includes mustache and beards. Just make sure everything is neat and tidy.

This post was most recently updated on 3/12/2015.

[techfogies]

Accomplished Resumes

Your resume is probably not the best it could be. What makes a resume stand out? Accomplishments, accomplishments, accomplishments.

Many resumes confuse responsibilities with accomplishments. Your responsibilities are important, but your accomplishments are even more important. How can you tell the difference? One way is to see if what you said is something you're supposed to do (on a daily or weekly basis), or if it's something specific that you did that achieved a result. The former is a responsibility; the latter is an accomplishment.

A list of responsibilities doesn't say what you actually did. A list of accomplishments says that you did things that benefitted your company and/or your company's customers. A recruiter or hiring manager is going to look at a resume with a list of accomplishments and see a person they want to talk to.

How do you describe an accomplishment?  A combination of the following: What the result was and quantify it if appropriate ("Reduced backlog of customer requests by 30%", "Deployed XYZ tool within the company") What the scope or impact of what you did was ("used by over 10,000 internal employees", "for five Fortune 500 clients") An indication of the time scale or schedule, if appropriate ("on schedule", "within three months") A possible indication if budget is relevant to the accomplishment ("on budget", "under budget") A very brief description of how you did it ("by improving internal project management system", "by developing automated tool"

A good list of accomplishments says that you get things done, and you get them done well and in a timely manner. That kind of person gets brought in for an interview.

This post was most recently updated 2/26/2015.

[techfogies]

Exploring Shells (not by the Sea Shore)

It's probably a toss-up as to which subject would generate the larger flamewar: your choice of editor or your choice of shell. As a Tech Fogey, my choice of shell has been the C-shell, first as csh, then later as tcsh (and I use vim). Recently I converted (initially kicking and screaming) to bash and you know what? It wasn't as bad as I feared.

One of the meanings of bash involves the nature of bash -- it's a combination of sh, csh, and ksh. It contains just about every feature I relied on in tcsh, such as numbered command history and a directory stack.

I've had to get used to hitting TAB-TAB instead of TAB for command or directory completion, and TAB-TAB instead of CTRL-D for command or directory expansion, but it's become natural now. File descriptor management is based on the sh model, but now that I use script and nohup more often, I seldom need to manage my file descriptors.

Since I've had to write rc and init scripts in the past, I'm a bit familiar with sh programming, so getting used to shell functions (which csh/tcsh doesn't have) took only a little time to get familiar with them, and now I've actually gotten quite fond of them.

So what's the lesson learned here? I think there are several points: 1) I didn't run to IT demanding they provide tcsh, so I wasn't seen as a troublemaker; 2) I proved to myself that I could adjust to this change, and even come out the better for it; and 3) this process makes me want to examine zsh and see what it offers. That kind of flexibility can only be a good thing.

This post was most recently updated 2/19/2015

[techfogies]

Automate Everything

If you're in the software industry, you should be heavily invested in automation. What should you be automating? Everything you can. For the moment, let's start with five areas: testing, deployment, rollback, monitoring, and statistics gathering.

Your unit tests and integration tests should be automatically kicked off once code is committed. You can use hooks in your software repository (whether that's SVN, Git, GitHub, or BitBucket) to run your tests and notify whether the tests pass or fail.

Obviously, the initiation of a push to production or code deployment should be manual, but once you start the command running, everything else should be automatic. There should never be further user input barring perhaps a 5- or 10-second sleep at the start so there's time for an interrupt in case of an accidental invocation. Ideally there should also be a lock so that code can't be pushed or deployed if tests fail.

There should also be a way to automate the rollback of the latest code commit (or multiple commits) with a subsequent automatic push or deployment. This is so your operational staff can fix a broken system without needing the developer(s) to rollback their code, and so that the operational folks don't need to know how to do a rollback.

All monitoring should be automated as well. Uptime and performance thresholds should trigger automatic procedures to try to fix the problem; if those fail, then notifications should be sent to a human. Ideally these monitors should be run from both inside and outside the DMZ, and if you run in the cloud, then by all means include any monitoring that the vendor supplies. You could even have one cloud vendor monitor the performance of systems running in a separate vendor's cloud.

Since you're monitoring, you should also be saving those measurements to compare over time, both short- and long-term. For statistics gathered from outside your DMZ, you could punch a hole in your firewall, or just save all the stats outside, then periodically collect them from a machine inside the DMZ. You should find good display software that can let you show real-time and historical data.

Some of you may be thinking, if I automate all this, why will my employer keep me around?  First of all, how long do you think it will take to actually put all this automation into place? The answer is probably longer than you think. Seriously though, researching, deploying, implementing, tuning, and testing all will teach you a lot about automation, and I would hope a competent employer would want to keep around the person who just completed a huge project on time and under budget. If the employer is willing to let that kind of employee go, then you take all the knowledge you acquired and find another employer who does appreciate an employee like you.

This post was most recently updated 2/5/2015.

[techfogies]

Email Preferences

Email is likely the thing you do the most, after your actual work tasks (if you do more email than work, then something is seriously wrong). You might think the most important decision you have to make is whether to top-quote or bottom-quote (that's easy, you do what the rest of the company does), but that's incorrect. The most important decision when sending any email is what to do with the salutation, the first sentence, the complimentary close (or closing), and the signature.

If you're using the same salutation, close, and signature for every email you send, then you're not being as effective as you could be. Everybody has their own communication preferences, and if you adjust your message to the recipient's preferences, then you will likely get a much better response.

How do you find out these preferences? Go through your inbox or archives for every person you've emailed and look at their messages to you. Do they use a salutation at all? Does the salutation include your name or just a generic "Hi"? Do they get right to the point, or do they do a bit of chit-chat at first? Do they close with "Thanks", or something longer ("Thank you for your attention in this matter")? Do they sign their emails (I know one person who does not sign their email "since they know the message came from me")?

Now that you know their preferences, you can mirror them in your own messages to them. You can be briskly efficient to those who get right down to business, and friendly and outgoing to those who are more extroverted. To the briskly efficient person, you'd have a short greeting, a simple closing, and a signature. To the friendly outgoing person, you'd have a more elaborate greeting and closing, and a signature.

That leaves the first sentence. Just like the other three, tailor it to the preferences of the recipient. If they prefer getting right to the point, then make the very first sentence exactly what the message is about. If it's informational, say it first, then elaborate. If you're making a recommendation, then say it first. If it's asking for a decision, say that first. Are you sensing a pattern for this type of person?

For a more gregarious, outgoing person, your first sentence will be a friendly greeting. Ask them how they're doing, about their recent vacation or weekend, or how their spouse and/or children are doing. Only after that can you turn to the matter at hand.

Note that I'm simplifying the types of persons and their preferences. For a more elaborate way of classifying personality types, I suggest looking at the DiSC Profile.

This post was most recently updated 1/22/2015.

[techfogies]

Due Diligence in Documentation

Documentation is probably most people's least favorite task, with the possible exception of listing last year's accomplishments so your boss can write your annual review. However, the word "documentation" can be interpreted in two ways, and both of them can work in your favor.

The first meaning of "documentation" means keeping track of what you're doing and why you did it.. This means at the very least remembering what commands you ran and their output. This will help you in future debugging, since you will have these logs to look through. You can start off with your shell history, but that tends to be ephemeral, so you'll want to become familiar with the script(1) and nohup(1) commands which will save the output from your commands. Script will let you name the output file, but is vulnerable to your shell dying (if your network connection glitches) and killing the command. The nohup command will prevent this, but it always uses the same file name to store output in, so you'll need to remember to rename the file.

Some other things to note about script: most importantly, don't run an editor while inside a script session. I recommend configuring your shell prompt to indicate that you're inside a script command to help you avoid this. Also, the whole point of script is that you run your commands in the foreground (script saves both standard output and standard error), so you will see all the command output. If there's a lot of it, you might want to use nohup instead.  You can also use the screen(1) command to prevent your script session from dying when you lose connectivity.

If you're really into deep hacking, I suppose you could also use the tee(1) command, but that might be overkill for most purposes.

The second meaning of "documentation" is the one that's most often used. There are two ways to write documentation: for yourself and for others. For more information on documentation for yourself, see the post "Taking Note".

I will venture a guess that a major reason many folks don't write documentation for others is a fear that if all of what they know is written down somewhere, then they have no leverage against being let go (another reason is that they can't explain things in writing very well). It's viewed as a form of job security.

There are two things wrong with this point of view. The first is that it's likely to get you paged at 3:30 on a Sunday morning because something critical has broken and you're the only one who knows how to fix it.

The second is that it's unprofessional. The knowledge you've accumulated is not solely yours, your employer has a right to it as well. By hoarding it in an attempt to become indispensable, you're damaging the company and hurting your own reputation.  Nobody likes a greedy person, and your work relationships will suffer.

Instead, it's a sign of professionalism to share what you know. You are no longer the gatekeeper, but the teacher. Rather than get annoyed when you're asked about something you haven't chosen to share, you can instead say, "the documentation is here, have a read. If you have any further questions, let me know and I'll update it". By the way, if you really do get annoyed at being asked, then consider that you almost certainly brought it on yourself.

So where and how do you document? Use whatever system your company is in place: a third-party cloud solution, internal CMS setup, or even just plain HTML. If there's nothing at your company or you can't get permission to add documents, then you'll have to do it on your own. The most important thing is that it must be searchable.

One final thing: if you do go outside your company to set up a system, make sure the permissions are set properly. And use a completely different password in case you need to turn over admin privileges to your IT support group.

This post was most recently updated on 1/8/2015.

[techfogies]

Taking Note

I don't know about you, but my memory is weird. I can remember almost every commercial jingle from my childhood, and can quote almost every line from every original Star Trek and M*A*S*H episode, but if you told me that the cookie is called 'frobozz' and if it's value is 'baz', then THIS happens, but if the value is 'quux' then THAT happens, I've probably forgotten that at least a half-dozen times.

There's no shame in asking questions. There's no shame in asking the question a second time. Asking it a third time is starting to push it. The answer is simple: note it.

Taking notes is both simple and hard. It's easy because all you have to do once you hear something you want to remember is note it. The hard part is how. There's three choices: memory, paper, and computer. Given the premise of this post, memory is right out.

Paper is quick and cheap; you can draw diagrams, use different color pens or pencils, and it doesn't need AC power. On the other hand, you can't index or search paper very easily. And if you're like me, sometimes you can't read what you wrote down only yesterday.

What about a web or dedicated note-taking app on your laptop or tablet (or even just NotePad or TextEdit or vim)? You can probably type faster than you can write, and if you're using a cloud-based app (like the popular Evernote), you can easily organize and search your stash of notes. Drawbacks of computer-based notes are the difficulty of drawing a diagram (can you take a picture from your laptop?), potential reliance on AC power, WiFi, and the Internet, the requirement to constantly carry your laptop around, and the sound of your keyboard in a meeting.

Here's a possible compromise approach: when you're in a meeting (or otherwise away from your desk), take notes on paper, since that gives you the most flexibility. Then when you're back at your desk (or somewhere you can type), copy them into your note-taking application.

This post was last updated on 12/12/2014.

[techfogies]

Relationships Rule

The "generation gap" exists in the working world as well.  If you're a Tech Fogey, then it's likely that almost all your cultural references (original Star Trek, East Germany, pay phones) are a complete mystery to your younger co-workers, and similarly theirs will be a mystery to you.

It's important that you find a way to bridge the cultural and generational gap, because your success will depend on having good relationships with your co-workers.

That may sound strange to some of you fogies.  Isn't doing your assigned work on time and with good quality the standard you are measured at? Yes and no. What will really stand out is being effective. And having strong relationships will make you more effective.

It's almost impossible to actually do all the work assigned to you without needing someone else to do something as well. If you have a solid relationship with that other person, then you can ask that person for their help, or to do their thing a few days earlier, or move your request higher up on their list. People do favors for people with whom they have good working relationships.

If you don't have a good relationship, you're likely to hear, "I'm really busy right now". or "It's on my list of things to do, I'll get to it", or "Let me get back to you". Receiving those kinds of responses will not make you effective.

How do you build a good relationship with someone? That's a huge question (and one that won't be answered fully here), but one place to start is finding shared references. Instead of being the grumpy curmudgeon who gets annoyed when a coworker doesn't understand one of your "outdated" references, take the time to research and understand theirs. Make a sincere effort to reach out to them, and you'll likely get a smile and a helping hand in return.

This  post was originally published on 12/5/2014.

[techfogies]

The Virtue of Virtual Machines

If your employer provides you with a computer (desktop or laptop), then you may have difficulty with doing personal tasks on that computer. It's not likely that your employer has installed a keylogger, but you will not want to allow your browser to store any personal passwords, especially if your computer has any automated cloud backup software installed. Cloud-based password storage applications can help, as can simply using your own laptop, tablet, or phone.

Another solution is to install a virtual machine on your work computer, ideally with full disk encryption. As long as you lock your sessions, or logout, or shut down the virtual machine, and you do not enable auto-login on startup, your data there is unreadable by your employer.  Yes, they can get a copy of the virtual disk (off your computer or the cloud backup), but if it's encrypted, then any personal data you have on the virtual machine is secure.

If your employer supplied a Mac (called the host machine), then you'll want commercial virtualizing software like VMWare or Parallels). For Windows machines, I haven't any experience (please comment if you do). If your employer supplied you with a Linux machine, or if you want to use free software, you can use VirtualBox on a Mac, Windows, or Linux box!

As for which operating system to virtualize (called the guest operating system), Linux is probably your best bet. You'll need a separate license to install Windows, and legally you cannot virtualize Mac OS. Many versions of Linux offer full disk encryption. This author uses Kubuntu.

This post was originally published on 12/2/2014.

[techfogies]

Welcome to Tech Fogies

Welcome to Tech Fogies, a blog dedicated to the older, more experienced technology worker.

This blog is a “rebroadcast” of the original Tech Fogies site and is written by the same author.

This post was originally published on 11/29/2014.