bbrock

Author: bbrock

Distractibility

Leave a comment

Distractions can drive almost all of us crazy. Some of us far more than others, and that means taking extra steps to minimize the impact of distractions, either by masking or preventing them.

For a start, I need some kind of low-level stimulation to stay focused. How that works is slightly complicated, but it’s a pretty hard-and-fast rule for me. For example, if I’m driving, the radio is probably playing. From experience, I know that it’s safer for me to drive that way, because my focus is higher.

Also, like most humans, I take a while to get into the “zone”. Also known as hyperfocusing on one topic while ignoring almost everything else. It’s a great state of mind and I try to spend as much of my working day there as possible. My productivity is in a different league.

  1. Background music. I’m partial to Amazon Prime, but a phone with a few playlists works as well. The music needs to be familiar, rather than new tunes. Motivational music is great for motivating me to get started, but not so much to keep working.
  2. Noise generators. I like myNoise, depending on mood. When I’m hyperfocusing, I use this much more frequently than music.
  3. Regular routines. I don’t want to spend extra time in the morning focusing on unimportant details. Grind the morning coffee beans the night before, set out tomorrow’s clothes, organize and pack a backpack, and put a few items on a paper planner’s todo list.
  4. Todo lists. On the phone. Lists for daily routines, groceries, errands to run, and phone calls to make. I keep a few on paper, specific to the day.
  5. A planning system. A Google calendar is great for appointment reminders and due dates. I also recommend a paper planner, with a page for each day. I’ll mark blocks out time until my day is full, including known breaks. At the end of my day, my written list of things I did and didn’t complete is in front of me.
  6. Escape from firefighting mode. This can be difficult. I try to set aside short breaks from the action when I will not handle problems unless they’re emergencies, even if it’s the beginning or end of the day. It’s vital to burnout prevention. Almost every job has parts that need to be done but tend to be set aside when fires are being fought.
  7. Sleep. Learn how much makes you feel most well-rested and stick to that. Your overall day will be much more productive if you’re in the sweet spot, not just doing the minimal required amount to make it through the week. The sustainable amount is the amount that will work for you, if you sleep the same length of time every night.
  8. Eat well. Hungry people are rarely energetic. Some become grouchy. My diet is plant-based (I’m vegan), which is far healthier than when I consumed animal products. For example, I stopped feeling tired an hour after lunch.
  9. Stay healthy. Probably obvious, but work to maintain your health. Few of us stay healthy continuously. Even minor health complaints get in the way far less if I’ve slept well and exercised (especially cardio exercise).
  10. Work from home. Sometimes. My work at home is often better than the office. I still recommend going to the office several times a week. But office environments can be highly distracting, with high levels of noise and interruptions from coworkers. I need some time to myself to just get things done.

diversity

Leave a comment

When we’re polite, we use the term “diversity” to say that the expected level of bigotry is absent. It’s a positive trait for an organization, right behind “does not induce psychosis”. It’s a selling point in software engineering, because it’s closer to the exception than the rule. It’s also good business, because mixed-gender businesses are more successful. The same trend shows up when looking at mixed-gender engineering teams.


Historically, gender inequality in software development has been due to a series of filters at every stage of education and career. It starts in childhood education, with a bias skewed in favor of men on SAT scores, regardless of ability. Fewer women take the advanced math courses in college that are required for a CS degree. Fewer of those major in CS, and then again fewer of that graduate with a computer science degree, and then fewer of the remainder continue on to careers in software development. Even with careers in software development, women are more frequently in supporting fields like documentation and tech support. Those positions typically pay less, as well.


In college, my CS classes typically had 20 students, and half were entirely men. About 5% of my class was female, at a university with more women than men (60%).


Most of my coworkers have looked like me. When I was a worker bee, my 2nd-level manager was a woman twice, as well as one direct manager. Out of roughly a dozen managers. Half of the engineering teams I’ve been on (typically 5-10 people) were entirely men. But the details varied, telling me that individual employers and managers can improve. I’ve heard HR reps brag that 10% of an engineering team was female, as if that showed diversity.


Fewer women work for many startups. That’s not surprising to me, as quite often startups have younger employees… who may be at child-bearing age when the required absences may not be tolerated as well by peers. They might already known each other, perhaps also have been classmates, and my experience says men band together and consider women a special minority who stick out. There’s a bias in venture capital firms, with success showing no gender difference when venture capitalists are women. Small businesses (startups) are also excused from the strictest employment and hiring laws. As a company grows, people hire others who are like themselves. This can be fixed partly by improving a startup’s environment. Staff adequately, allow time off, allow working from home, provide 12 weeks paid maternity and paternity leave.


Some guys think it’s ok to be a bit sexist on the job. I’ve asked why women generally avoid the field at past employers, and the women think those guys are the most obvious reason. Seriously, if someone’s a jerk in that regard, you should consider firing them for it. Quit excusing or defending their disruptive behavior.


The bias doesn’t exist everywhere. When I worked for NASA half my peers were women, more than at any other point in my career. That was also the highest-performing organization I’ve seen. As a tech writer, most of my coworkers were women. I attended meetings where I was the only guy. Even then, my management chain all the way to the top was entirely men. In development teams with colleagues in other parts of the world, the gender ratio was closer to 50/50.


The entire software development field can improve. When venture capital firms are run by women, there’s no gender gap in the performance of the startups they fund. However, the current trend is for fewer women in the field each year.

job searching on the internet

Leave a comment

I’ve been in the job market a few times in my career, usually without my employer’s knowledge. Most of my employment after college resulted from knowing the right people. I had a neighbor who worked at the agency. Or had known an employee since high school and through college, who delivered the resume to HR.

I’ve taken a look at a couple of online job search tools, Monster and LinkedIn. So far neither has panned out as well as other methods.

Many people seem to use LinkedIn like a social media homepage, but aren’t hiring from there. I get a lot of spam. Most of the job postings I respond to are for jobs which the employer (or more likely, their recruiter) can’t actually remember posting. Typically when they call, they ask questions like what field I’m interested in, as if they’ve never seen my resume and don’t know why they called, after responding to specific job postings. Several have asked if I had extensive experience in fields unlike anything on my resume, such as sales or finance.

Monster has given me quite a few leads. But about half of the job offerings I apply to have already been closed. The recruiters I have spoken with as a result have not always been the most useful, even after they knew me. During one interview, I was quizzed about which technologies to use by a CTO who then said he wasn’t actually looking to hire anyone.

buzzwording

Leave a comment

If you work in software development very long, you learn that people who sell technology not only use buzzwords, but invent them on the fly. Once they start to catch on, or are repeated by senior-enough management, everyone uses them in a sophomoric attempt to be one of the cool kids.

Here’s a partial list that I’ve gathered over the years, of the worst that really didn’t need to be used as shorthand for anything:

  • Out of the box
  • apples to apples (comparison)
  • the net net
  • change the paradigm / paradigm shift
  • basic blocking & tackling
  • The (Home Depots, Walmarts, McDonald’s), when referring to other companies of the same size.

Don’t use those. You need to maintain your buzzword capital, and that means not squandering it unneccessarily.

In addition to those random buzzwords and phrases, IT and Computer Science require extra words to describe complicated processes quickly. For instance, every job I’ve interview at in the past 6 months has assumed that I can define “sprint”, and correctly identify what happens well enough to explain how my own processes deviated from ideal. New programming methodologies (like scrum, which weirdly rejects its proper noun status like it’s e.e. cummings or k.d. lang) introduce their own vocabulary. That vocabulary provides and assumes a context. Those are the buzzwords you really need to know and learn how to use effectively. Use them correctly when communicating with others in the field, and you’ll look like someone who pays attention rather than someone who’s blindly grasping at trying to be cool.

Spectre and Meltdown

Leave a comment

Unless you’ve been living under a rock, if you work in IT you’ve heard of Spectre and Meltdown. As you’ll see in a moment, Meltdown is a specific example and exploit of a class of weaknesses called Spectre that affects basically all computer hardware made in the past decade or more. On systems that are affected, the exploit allows an unpriveleged user to peek at anything in the system’s memory, regardless of permissions.

The suggested fix is to replace a systems CPU with new hardware… that hasn’t yet been created, or at least not released publicly. There are a few ways to shore up the operating system’s defenses and security, but it will definitely be available as a backdoor to anyone capable of misusing them.

One of my favorite youtube channels, Computerphile, posted a video several weeks ago that helps clarify what’s going on (comp:

I’m usually a bit annoyed with any company that has serious security flaws, and realize it’s not always justified. I tested software errata with security fixes long enough to have a fairly quick understanding of how a software project goes through the steps that lead to releasing specific fixes.

First of all, I don’t blame anyone in Quality Assurance for not finding the issue. It’s a design flaw, and in some environments the common reaction is to ignore QA when they point those out. I’ve been told several times that a flaw which I found in Quality Engineering was not serious, because it was in the last release and no customers have yet complained about it. Also, it’s not easy to find security flaws in software quickly, even for those trained in the dark arts. Quality Assurance and the tests they devise are designed to prove that software can work as intended without problem. Unfortunately, you can never test bugs out of existence, and the sheer volume of code required to try would dwarf the size of the software intended for release. The best you can do is say “it didn’t work like claimed” if the actual tests don’t pass.

By the way, in the vast majority of cases that I’ve seen, QA spends the most time working on regression testing, preferably automated. Meaning that the tests they devise passed for the previous release, and QA is checking to see if any relevant bugs occur again, after they’ve already been fixed once. Really, no one thinks QA is sexy.

Spectre is a cross-platform problem that is independent of operating system, and affects all of the major CPUs created to run more than one program. Basically everything except embedded systems like Arduino (I really need to check whether it’s affected). If it runs anything like a desktop or server or laptop, it’s vulnerable. So it’s not something that would easily be picked up by operating system creators.

The bug has been around for most of the careers of most hardware developers. It’s going to be a while before we really work out the best solution.

startups

Leave a comment

I’ve been a worker bee with some team lead responsibilities at a startup. I’ve noticed trends in employees in that role. Startups have a feeling and culture that just doesn’t exist in other companies.

At one point, I worked in a tech support call center (about 10 employees) where 25% of the people previously did some kind of EMT-related work in ambulances. They dealt with customer emergencies more sanely than any other employees. If they were flustered, they kept working at the customer’s problem.

But employees often help coworkers with burnout. The savvier coworkers may do so preventatively rather than in reaction to signs of burnout. Also, there are often social events at a startup, some during the workday at key milestones. Those lead to employees seeing each other when they’re less stressed than during the workday, and provide crucial perspective.

In a startup, devotion to the company is more widespread. Folks at startups might hail from the same school, with similar ages and other demographics. If you’re growing a company, be sure to stop potential ageism and sexism before it becomes a larger issue. Personalities run strong and people tend to be driven. But more importantly, work is often treated competively as a contest of who can handle the most.

Don’t expect folks to stick around a startup forever. They may cash out when the company is bought, goes public, or grows even grows substantially. Those things all tend to alter a company’s culture to make it different from a startup. Also, employees might launch their own startups, possibly to be acquired by the company they left when both have grown. So pay attention to coworkers’ side projects.

You have to pay better attention to your health. Startups have longer hours, more stress, suspense, and unhealthy food and eating habits. Often the environment isn’t good – it’s a converted warehouse that’s still drafty and has an echo, it’s cramped, or its even temporary and changes quickly. Burnout and depression can affect employees outside of work. I’ve known several people who were divorced because they stayed at work late too much. Eat, drink, and sleep like those activities are bigger investments (they are) than the startup. Get some cardio. Make a stable routine. Take a real vacation every 6 months.

Some startups earn a reputation for valuing employee health or taking advantage of employees in unhealthy ways. I’ve seen a bad reputation like that sink a small business (web development, ISP) when it should have fluorished. Consider that interviews for places that promote employee health are often much more difficult places to land a job.
That higher retention of good employees is key to a company approaching profitability.

If the company sets the curve early in its life, it leads to some very sane HR practices. It also develops the skill of rapidly coming back up to speed after an absence.

Run it yourself.

Leave a comment

I’ve worked on projects where one of the developers never ran their own code.  Never.  The results are obvious to everyone with 6 months of experience in QE.  It’s annoying and can come across as condescending.  Also it’s frighteningly naive.  That’s how segfaults during startup happen.  Or worse yet, entirely new features being completely or partially untested, if a developer is quiet about expected new output that QE never sees happen. So for the love of Kernighan & Ritchie, run your code just once as a smoke test before passing it along to the build process that ends in QA.

It doesn’t take very long. In QA it’s the first thing that I do, it’s just smoke testing at that point. Basically, determining if the build appear valid. By the time I’ve completed the part of integration testing covering the new features, I’ve spent 30 minutes setting up systems in a new configuration and 5 minutes testing. Many days I’ve tested something and the new feature immediately fails horribly, often badly enough that I can’t see how the feature worked at all.

It seriously helps to setup a test build system for pre-QA builds. It’s a couple of hours’ work once, and less than 10 to check out a build during development. It can save 1-2 hours / day for QA, frequently where the bottlenecks occur and at the most inconvenient time. I’ve seen software respin 3 times / day at various points, because of the lack of pre-QA smoke testing.

There are obvious ways to work around this in QA. They still require attention from QA, who will be logging the build’s status and initial smoke test results. It’s often a distraction from other testing in QA. I’ll cover that ground for QA in another article.

a Linux career

Leave a comment

I started working with Red Hat Linux, Fedora’s predecessor, in roughly 1996. At the time, friends and I at JMU were establishing the school’s Linux Users Group. Red Hat was kind enough to offer some limited sponsorship, in the way of software for our group to share. We set up a mailing list and quickly gathered a large group that surprised everyone in the beginning.

My junior year, I went to LinuxCon, the conference in Durham, NC that Red Hat sponsored. It was small, only about 100 people. But there were a few very top kernel developers associated with Red Hat, even then. The friend who I went with scored a hard drive as a door prize. I scored a copy of Red Hat Linux that Red Hat didn’t even make themselves yet. I also picked up my Red Red Hat Hat, with the “alpo” logo, sold to me by none other than Bob Young. Even then, he was one of the most humble business people I’ve met, convinced he was almost out of place working with fledgling industry giants.

A couple of years later, just before I interviewed at Red Hat, I had the good fortune of seeing what that looked like behind the scenes. It was clear to me then, that Red Hatters were a special breed of committed, highly competent geeks devoted to revolutionizing the industry. It wasn’t just t-shirts and free beer, although there was some of that.

For most of college, I worked summers at a small dial-up internet service provider (ISP). We made our real money selling web development to realtors getting in on the internet at the ground floor. I designed a few sites, which in hindsight was a fairly scary assignment for a newly-minted engineer. By the time I left that ISP, I was their system administrator. That’s right, I was a team of 1. In the end, they were just too small to provide the benefits I needed, so I entered the corporate world. I had a linux system in our quasi-colo facility, and knew that many of our competitors exclusively ran linux.

I took a brief hiatus from doing the Linux thing professionally for a job with a telco, where I honed my Perl skills. About 14k lines worth, in one project. They weren’t yet ready for Linux. In those days, the first wave of Linux developers and sysadmins were leaving college and turning their hobby into something that earned a paycheck. Linux was still sneaking in the back door.

By the time I reached NASA a couple of years later for another sysadmin gig, Red Hat Linux was the base desktop for my users. We used Solaris servers, one or two of which I actually EOL’ed for Y2K compliance. While I was there, it was easy to recognize that every bit of NASA was populated with highly talented people. It was an honor to work among them.

Then I started working in tech support, developer support, and into engineering for quality assurance. I worked in that role for a little more than 15 years, during which time my employer rode the Linux wave from 200 people to 10,000. From the time I walked in the door to my employer, I needed to constantly learn just to keep up. I’d often hear about new technologies as someone talked about implementing them, or as I began testing them. Working inside a company like that presents its own challenges, that I’ll save for a later time.

Looking forward, I’m going to stay involved with Linux. My expertise is with Red Hat’s offerings, but of course I’ll branch out a bit into other distributions. I’d like to
continue my career trajectory through virtualization technologies, I feel it’s still a field that’s maturing. To be honest, I want to stay at the forefront of Linux development. It’s addictive in a fun way, after all of these years.

A brief history of the solar system

Leave a comment

I’m somewhat fascinated by the timeline of humans discovering something about the size of the solar system. A lot of people assume that Copernicus was the first to propose a heliocentric model to explain the apparent orbits of the planets relative to Earth.

But the real story goes back a bit further.

The foundation was laid by Euclid in 300 BCE, creating much of the modern understanding of geometry recognizable to students today. For the next 100 years, his new understanding had a profound impact on astronomy as astronomers and mathemeticians pieced together the geometry of the solar system.

Between 300-200 BCE, Greek astronomers and mathemeticians came to several conclusions that provided estimates of the relative position, motion, and size of the Earth, Sun, Moon, and naked-eye visible planets. The shape of the Earth’s shadow on the moon is obvious, if you’ve done enough astronomical observations. You know when the Moon and Sun are on exact opposite sides of the earth, and that corresponds with a lunar eclipse. That informed the acceptance that the Earth, Moon, and Sun are all spheres flying through space in roughly circles. The Greeks knew enough geometry to understand this was simplest and most accurate when a heliocentric model was used. It was practically an observation. Beyond that, it made sense and was easiest to use a model with the planets orbiting the sun in their correct order.

People had been predicting eclipses for some time, already. The saw the shape

Aristarchus discovered the ratio of the Earth’s radius to the Moon’s, and to the distance between the Earth and the Moon. It also gave a distance to the Sun and its size in Earth radii. The numbers are the correct order of magnitude, meaning that they had a sound working model showing the moon was a good fraction of the Earth’s size and 100s of thousands of kilometers away. Notable, the distance to the Sun, and consequently its size, were calculated at 19-20 radii, when the real number is closer to 390. Basically, it was hard to measure whether an angle to the sun was 87 vs. 89+ degrees. Separately, Erastosthenes derived the size of the Earth based on the angle of shadows at two points on the globe at noon on the equinox. In doing so, he measured the curvature of the Earth and learned its circumfrence and radius. He was within 16%, possibly within 1% of the actual size of the Earth.

All of that happened 280-200 BCE. They were briefly controversial, but probably never heretical ideas to the Greeks. Euclid developed a very new, much more accurate understanding of geometry that students today would recognize, around 300 BCE.

By 150 BCE, the moon’s distance was estimated as 380,000 km. The actual number is 384,399 km, with a range of 362,000-405,000 km. This simultaneously pulled the other estimates of the solar system’s measurements into something similiarly accurate.

In defense of exploratory testing

Leave a comment

Exploratory testing is basically what everyone unfamiliar with the work thinks QA spends all of our time doing.  Naturally, it’s not the most sophisticated view, and it’s a topic that’s been basically irrelevant to the past 20 years of Quality Engineering.  Good exploratory testers are like rockstar programmers; very powerful most of the time but not as reliable because they spend more of their time innovating rather than maintaining.

To find bugs as soon as possible after they’re inserted into code, you need to find the bugs that cannot be individually predicted.  You probably don’t know exactly how the software you test is going to break next.  If you’re load or performance testing, you probably don’t have a solid expectation of the results before the first few runs.

So it’s best to know what you’re dealing with, to get the exploratory testing under control and make it as useful and efficient as possible.

James Bach’s article on Exploratory Testing