Not long ago I started a job with a company whose primary product is a very custom application that is comprised of many smaller interoperating applications. Without getting into too much detail, the applications communicate through various APIs, many of which are not well documented.
(What follows are thoughts that are not focused solely on the new employer, but rather a set of experiences I've gathered over the years from several jobs and interactions with others in the technology field. In other words, this isn't about the current employer. It's a conglomeration of experiences, and it's my own opinion. Just figured I'd have to clarify that...)
As a company focuses on growth, there comes a time when maintenance and monitoring is moved to staff that are dedicated to those tasks so the developers no longer have to do triple duty; for the new hire tasked with pioneering that position, gathering statistics to get a feel for the behavior of their systems over time, and taking care of regular maintenance and basic troubleshooting is very daunting when there is little (or no) documentation available outlining how to get the necessary metrics for gauging the health of the system.
And it isn't just a lack of documentation that acts as an obstacle. When a software-based company is first conceived and grows, it's natural for the programmers to work on getting the product into a usable, testable state. This means overcoming problems as they arise and focusing on results, not laying framework for delegating future operations.
That fosters institutional knowledge. The more of your system that is developed in-house, the more information future maintainers must glean about your system without help of outside references. Sites like Serverfault can help when you're trying to figure out why a new deployment of Nginx won't work, but it won't be useful when a log contains output from a Java application Bob, three desks away, wrote while debugging a particular reply encountered from another subsystem's API response.
Small companies with a small number of developers may feel it is inconvenient to be interrupted by the new person's constant questions about why application A is dependant on application B, or how application C discovers a service status on server 3. As a new hire, I feel a little hesitant to approach others with these types of questions, preferring to try looking for answers through other means before taking someone else's time.
(In my opinion, if the answer is to check the source code from the repo and read that to get the answers, you may as well have hired a new programmer; recognizing a need for someone dedicated to operating and maintaining your system outside the coterie of coders is a sign that there may be a need to dedicate time to documenting and tooling the application for non-programmer use.)
How can a new hire get a grasp on this situation?
In this case, I've been writing a series of Nagios plugins specifically configured to pull metrics from the various subsystems in the company application. There are cases where I thought a simple task was actually more nuanced that first appeared; each time, I ended up discovering something more about the operation of the system, and I made sure it was documented for later reference.
Each time there's a failure case, I would make a note and start work on a new monitor so we'd know about it in the future. These monitors didn't just collect a snapshot of the current state of a service, it would gather some metric that was then sent to a database and from there plotted on a graphing application for performance monitoring.
The current product relies on database performance; some queries behave different from others, where some are straightforward and others require processing of filters. Some of my checks measure response times.
Others are querying API endpoints for replies of what the services believe are their current health states.
Some queries are pulling the status of database indexing.
In cases where the application is exposing information through Java beans, my plugins are pulling numbers from JMX and checking for values within established expectations.
In other cases, plugins are checking for the existence of files that are supposed to be regularly updated and when certain records are updated in the database.
Each of these plugins, once finished and deployed, are being documented for operation in a way that when new people are hired he or she should be able to easily find a list of how these work and gather indirect information on some aspects of the in-house application operation without programmer-level institutional knowledge.
In the case of my new position, I've gained a higher respect for the value of meta-applications in gaining insight on how a complicated system works. Having information written out or explained to you is enlightening, and I never feel that documenting how something works is a waste of time. But until you find yourself executing on that knowledge, I'm not sure you really understand the subject. Creating support applications that meaningfully interact with the system pushes knowledge into the realm of wisdom the way reading about the science of flight comes alive after building your first remote control plane.
When confronted with the task of comprehending the colossal, try learning about the limited first with applications that monitor and interact with small aspects of the system. Not only will others benefit with the support applications, but you'll benefit with the mental exercise and in the end have a better model of how everything works!
Showing posts with label Workplace. Show all posts
Showing posts with label Workplace. Show all posts
Saturday, April 29, 2017
Wednesday, April 13, 2016
Athens School Board's Response to the 2016 Threatened Strike; Disingenuous Again
The teacher's Union has finally...after over 3 years of negotiation stalemate...threatened a strike.
The School Board responded pretty much as I thought they would; they quickly put up a rope and aired their version of the dirty laundry. And just as relevant, they blamed the teachers for making the britches dirty even though it's their crap on the backside.
The Board posted, on the school website (which still pisses me off as the Union can't post information to the school website for their side of the story, but the School Board likes to post propaganda to the front page of the district site, making it harder for the public to actually piece together a coherent picture of what's going on if they are so inclined), their "Responsnse from the AASD school board.pdf." (The typo is theirs; I thought it amusing, so I pointed it out, although they may change it later).
They start off painting the teachers as evil, untrustworthy and shifty. In their response, the Board used phrasing such as, "We would like to add that at no time has the Athens Area School Board negotiation team members met at the table, unwilling to negotiate" to insinuate that they are the victims of a vicious Union (although phrasing is kind of important, since this sentence could be read as they simply never met at the table...). They say, "We have not put unrealistic timelines or demands on the AAEA, while that has not been the case by the AAEA." That's strange, given that the opening of the paragraph states they've had 3.5 years with no meaningful movement in negotiations.
After setting up those dominoes, the Board points out with evident self-satisfaction that the Union reneged on their official statement from November 2015 that stated they would allow a deadline of four weeks after a state budget was passed for a reasonable settlement to be proposed.
The state budget was officially allowed to lapse into passing on March 27th, and here we are with a threatened strike STARTING ON APRIL 18th! THOSE LYING UNION BASTARDS! They even ended the paragraph with an unsubstantiated claim that they offered to meet for negotiations but the AAEA "simply would not meet with us." In summary, "You can clearly tell we're victims of these horribly unreasonable jackbooted thugs." You can almost picture them cringing as the teachers march into the room in full uniform regalia, drooling in anticipation of crushing the kindhearted and well-intentioned School Board under their collective bargaining heels.
And they're right! The Union did take a strike vote in less time than promised. However, the Board failed to emphasize that the ultimatum was for a reasonable proposal and show an attempt to bargain in good faith. That's really a weak ultimatum. It's like telling your kid they better not hit their sibling again or you'll maybe punish them. Reasonable proposal. Show an attempt. And how did the Board react?
They weren't lying, but they weren't entirely truthful. Here's a handy link to the census information at Census.Gov. It's kind of weird that the Bradford County household income is $48,000, but the US average is $53,000 and Athens Township has an average income of $51,700. But I guess the $48,000 statistic paints a more outrage-inducing picture.
And in Athens, the major industries are...hospitals...the school...and...what? Most of your business booms are fast food, Wal-Mart and new hotels. At least, those are the visible new jobs. City-data.com says Athens' most common industry is manufacturing (27%) and the most common occupations are production- and construction- related (15% and 12%, respectively.) Knowledge workers with higher degrees seem to leave the area.
The Bureau of Labor Statistics says the median weekly earnings of a person with a Bachelor's degree (2015) is $1,137. There's 52 weeks a year, so that comes to a little over $59,000/year. Strange...that's not too far from the teacher's salaries. Master's degrees earn about $1,341/week, or $69,732/year.
That means the teacher income average in Athens, at $66,000/year, is well within the "average" mark. A high school diploma average is $678/week or $35,256/year, for what it's worth.
I suppose the board would say that the $66,000 is still significantly higher than the average for having a Bachelor's degree. Let's take a quick glance at the data in the tables they published online to illustrate how overpaid their semi-anonymized teachers are.
Most of the staff were hired between 6 and 18 years ago! I count 27 people hired before 2000, 52 employees were hired between 2000 and 2010, and 18 from 2010 to 2015. Four of the 27 were hired in the 80's! There's a significant number of experienced staff! (Note I figured this up by hand from the chart the board provided. I may have a miscount. Feel free to double check, let me know if I missed something in the comments...)
And that's what the board is focused on. Teachers are expensive. Cut them down at all costs.
To further illustrate how unreasonable teachers are, the Board said they REFUSED to work an additional 15 minutes a day without being compensated. What they still refuse to acknowledge is that teachers already work this additional time. They're just not contractually obligated to do so during the school day. The Washington Post reported that the Bill & Melinda Gates Foundation along with Scholastic issued a report showing that the average teacher works 10 hours and 40 minutes a day. Yes...obligated to work 37.5 hours a week, but actually on average, working 53 hours a week.
From their web page:
The 7.5 hours in the classroom are just the starting point. On average, teachers are at school an additional 90 minutes beyond the school day for mentoring, providing after-school help for students, attending staff meetings and collaborating with peers. Teachers then spend another 95 minutes at home grading, preparing classroom activities, and doing other job-related tasks. The workday is even longer for teachers who advise extracurricular clubs and coach sports —11 hours and 20 minutes, on average. As one Kentucky teacher surveyed put it, “Our work is never done. We take grading home, stay late, answer phone calls constantly, and lay awake thinking about how to change things to meet student needs.”
Um...that's kind of awkward. It pretty clearly says that the fact finder report was yet to be voted on by the Union for acceptance when the Board already rejected it. October 8 of 2015. Unanimously. It's available on the labor relations board website, by the way.
But if you were to just read the Board response, the rejection was all on the Union. Funny how a simple Google search shows that insinuation is utter crap.
The next page had a listing for an article from June 2014 when the board once again rejected a fact finder's report (and this one pointed out the teachers accepted the report.)
And for all the calls for saving money, the Board seems oddly bent on wasting money in other areas. For example, they recently spent $15,000 on a study that told them they were wasting $800,000 on transportation. There's bound to be some variability in spending...but $800,000? It's kind of an amazing article to read. And the report, too.
The Board is also cutting two checks to lawyers. This has a bill from John Audi (Sweet, Katz, & Williams) in January for nearly $6,000. (also one to a doctor, Sidney G. Ranck, Jr., for $1,200...he's in obstetrics and gynecology. That's kind of...disturbing?)
This bill has John Audi getting a check cut for nearly $3,000. And this one is another $6,500 check, along with their second lawyer, Pat Barrett, getting a check for $6,000. The list goes on.
And this is in addition to the acting superintendent's $130,000 salary (strange that seems to be missing from the salary list the Board is holding up as evidence that teachers are overpaid...)
The interesting part of that salary is that the previous superintendent was getting about $122,000/year. The acting superintendent isn't qualified to be superintendent and he's getting paid more. Part of me wonders if it's a gender thing...but that would be speculation. He's literally not qualified. The Board is paying for him to take classes and get his certification. That's why he's an acting superintendent. The previous superintendent was hired away from another district and had several years of experience. The new one is making more money and doesn't have a certificate. Somehow the Board equates this with hiring the best staff as per their resolutions back in January of 2013.
Overall the whole "response," in my opinion, is one long exercise in misleading the public. Take the claims that they have been open to bargaining this whole time in good faith with a grain of salt. They claim to care about the community and educating the kids, but their actions demonstrate, quite loudly, otherwise.
ADDENDUM
I did some quick checking of how much the frugal school board is spending on lawyer's fees. These figures were taken by eyeballing the board bills found on the school website. These reports are in PDF format, making them really really difficult to process in an automated fashion. Since I couldn't process them automatically I may have missed some payments, so the numbers I have, assuming I didn't misread some line items, would be considered a minimum paid to two law firms over the past 3 years, meaning there are probably payments missing. I think the contract talks may have extended beyond what bill items are on the website.
Regardless, this kind of money is interesting given how much the Board speaks of money problems and how expensive teachers are. It's also interesting how much vested interest the legal counsel has in prolonging the contract talks. How many meetings are there for negotiations? How much are they making per meeting?
The numbers are all there, listed with dates the checks were cut. Feel free to double check my numbers and tell me if I'm missing something. Also, I'm aware that the solicitor for the board (P.B.) does other duties, so these are not funds spent only on fighting the Union; I'm not privy to the other duties, however, so I can't break down the numbers into sub-categories. I've been told the John Audi firm was hired just to fight the Union, however, so big numbers are still big numbers.
Update 4-17-16
One of the sticking points in contract negotiations is in regards to the number of consecutive personal days a teacher may take. But it strikes me as being rather odd...what do they hope to accomplish by limiting consecutive personal days when teachers only get 3 personal days per year?
The AAEA (Union) provided an answer with a FaceBook post.
A Board member wanted to "talk" (usually situations like this implies "complain", but given a lack of specific information, that again is speculation) with a teacher. Teacher was on vacation. School board member now just happens to be pushing for limits on teacher time off.
If the implication is true the push to limit personal time off is purely for personal reasons, not for the benefit of the community taxpayers. This is a vendetta as a negotiations sticking point. How many other points of negotiation are driven by purely personal reasons?
The School Board responded pretty much as I thought they would; they quickly put up a rope and aired their version of the dirty laundry. And just as relevant, they blamed the teachers for making the britches dirty even though it's their crap on the backside.
The Board posted, on the school website (which still pisses me off as the Union can't post information to the school website for their side of the story, but the School Board likes to post propaganda to the front page of the district site, making it harder for the public to actually piece together a coherent picture of what's going on if they are so inclined), their "Responsnse from the AASD school board.pdf." (The typo is theirs; I thought it amusing, so I pointed it out, although they may change it later).
 |
| A werd frum ower sponser |
They start off painting the teachers as evil, untrustworthy and shifty. In their response, the Board used phrasing such as, "We would like to add that at no time has the Athens Area School Board negotiation team members met at the table, unwilling to negotiate" to insinuate that they are the victims of a vicious Union (although phrasing is kind of important, since this sentence could be read as they simply never met at the table...). They say, "We have not put unrealistic timelines or demands on the AAEA, while that has not been the case by the AAEA." That's strange, given that the opening of the paragraph states they've had 3.5 years with no meaningful movement in negotiations.
After setting up those dominoes, the Board points out with evident self-satisfaction that the Union reneged on their official statement from November 2015 that stated they would allow a deadline of four weeks after a state budget was passed for a reasonable settlement to be proposed.
The state budget was officially allowed to lapse into passing on March 27th, and here we are with a threatened strike STARTING ON APRIL 18th! THOSE LYING UNION BASTARDS! They even ended the paragraph with an unsubstantiated claim that they offered to meet for negotiations but the AAEA "simply would not meet with us." In summary, "You can clearly tell we're victims of these horribly unreasonable jackbooted thugs." You can almost picture them cringing as the teachers march into the room in full uniform regalia, drooling in anticipation of crushing the kindhearted and well-intentioned School Board under their collective bargaining heels.
And they're right! The Union did take a strike vote in less time than promised. However, the Board failed to emphasize that the ultimatum was for a reasonable proposal and show an attempt to bargain in good faith. That's really a weak ultimatum. It's like telling your kid they better not hit their sibling again or you'll maybe punish them. Reasonable proposal. Show an attempt. And how did the Board react?
 |
| Yeah, seems reasonable |
The Union stated publicly at a school board meeting on April 12th, when questioned about this decision, that the negotiation team felt the Board was refusing to further negotiate after their last session as a member of the School Board’s negotiation team declared, “We have nothing more to talk about.” At that point, the Union’s executive team made the decision to ask their members to vote on a strike.
The next bit of the Board’s response is an outline of goals to establish how reasonable the Board is. Three are pretty clear-cut. The last one is fluff, as there's absolutely no way to measure it, but makes them sound like they care about something important. Be allowed to hire the best professional staff members? After they stated goals that equate to trying to save money and lower pay, during a three and a half year standoff? You don't want the best. You want the most naive new recruits, too inexperienced to know that you're beating them in the head with a switch from a whackin' tree while you're telling them you're doing them a favor. Pro tip: don't start off highlighting why you're being browbeaten for 3+ years by an evil Union regime while bravely fighting to reduce your teacher's benefits and pay only to end it by saying you're trying to recruit the cream of the crop to work for you.
Next, they decide to roll into the biggest issue, the nearest and dearest to the taxpayer heart—teacher salaries. Teachers are too expensive to hire! The Board repeatedly presses to not give retroactive pay (after over three years of refusing to actually settle the contract, pretending that when this one is eventually passed they won't have to immediately settle the NEXT CONTRACT because they couldn't do their job...) and lower the pay increases due when teachers increase their experience/education levels. They do this by appealing to the public's basic grasp of math, because nuance is hard.
TEACHERS MAKE $66,000 A YEAR ON AVERAGE! THE AVERAGE BRADFORD COUNTY INCOME IS $48,000! HOW FAIR IS THAT?! They even published a table of teacher salaries; they were kind enough to omit the names, but it wasn't really much of a kindness. Teacher salaries are public knowledge. While the table they provide is semi-anonymized, the data has enough information to combine with the links to the (slightly out of date) data for public teacher salary records to figure out who is who, with a bonus of now knowing their employee identification numbers used in internal business records. So, yay for more "here's how you phish for data" handed out.
Holy shit. That sweet Bill Gates paycheck must be why the teachers be rollin' in to the parking lot with diamond-encrusted Lambo's and gold-trimmed Porsches. Sounds pretty bad. Why do they get so much when I don't!? The Board doesn't link to the document from which they pulled the numbers, but mention it's from the US census.
They weren't lying, but they weren't entirely truthful. Here's a handy link to the census information at Census.Gov. It's kind of weird that the Bradford County household income is $48,000, but the US average is $53,000 and Athens Township has an average income of $51,700. But I guess the $48,000 statistic paints a more outrage-inducing picture.
But is that the whole picture? Probably not, considering that income tends to be tied to education level. Teachers are required to have ongoing education credits. Basically the government tells them they need continued schooling or some equivalent (One of the step items the Board wants to not pay them extra for having attained) in order to retain certification. Nearly 88% of Bradford County aged 25+ (and 90% of Athens Township) have high school degrees or higher. But only 17% of Bradford County (and 23% of Athens) has a bachelor's degree or higher!
And in Athens, the major industries are...hospitals...the school...and...what? Most of your business booms are fast food, Wal-Mart and new hotels. At least, those are the visible new jobs. City-data.com says Athens' most common industry is manufacturing (27%) and the most common occupations are production- and construction- related (15% and 12%, respectively.) Knowledge workers with higher degrees seem to leave the area.
But of the educated, what are their average incomes? The Board is comparing a large population of mostly non-degreed members with teachers, who not only have at least a Bachelor's degree, but are required to continue with education in a rather specialized niche. It's not uncommon for teachers to end up with master’s degrees or higher. They're almost forced to.
The Bureau of Labor Statistics says the median weekly earnings of a person with a Bachelor's degree (2015) is $1,137. There's 52 weeks a year, so that comes to a little over $59,000/year. Strange...that's not too far from the teacher's salaries. Master's degrees earn about $1,341/week, or $69,732/year.
That means the teacher income average in Athens, at $66,000/year, is well within the "average" mark. A high school diploma average is $678/week or $35,256/year, for what it's worth.
I suppose the board would say that the $66,000 is still significantly higher than the average for having a Bachelor's degree. Let's take a quick glance at the data in the tables they published online to illustrate how overpaid their semi-anonymized teachers are.
 |
| Interesting how the median looks like a middle finger |
Remember that bit the Board claimed about wanting to hire the best? Unless your job makes you bitter you usually get better at your job with additional experience.
Unfortunately that's the garlic to the Board's vampire. These are educated professionals; a significant number of them have decent experience, and have been getting continuing education. That means they're going to be closer to the upper pay limit both because they've been there a while AND they have paper saying they're smarter.
In other words, you're paying for people who are better. And the Board doesn't want to pay them. I wouldn't be surprised if part of that spike in 2013 through 2015 is comprised of inexperienced graduates...they're cheaper.
The Board’s information about the teacher work day is also misleading. Teachers are obligated to work 7.5 hours a day with a half hour duty free lunch (SLACKERS!)
The language in their response is kind of funny. "Only work a 7.5 hour day." The 40-hour workweek, when I last checked, was comprised of 5 8-hour days. Even McJobs are required by law to give you 30-minute lunches when you work over five hours in a single shift. Plus breaks. The board is complaining that the teachers aren't obligated to work the hours of an hourly fast food worker.
Well, not quite. The board goes on to complain that in addition to the 2.5 hours of lunchtime they get a week, teachers are allowed 3.75 hours per week of self-directed time. THEY WERE EVEN ALLOWED TO GO TO WALMART OR THE BANK. It's like the inmates are running the asylum. I'm pretty sure at one point the Board proposed adding instructional time by having staff wear diapers to save trips to the bathroom. (That 3.75 hours was roughly 45 minutes a day. According to most teachers, this time was usually used to correct papers and prepare for another class period. They weren't watching Netflix or leaving en masse to get more adult diapers from Walmart every day, although I can see why the Board would be horrified that teachers would run an errand while stores were open.)
From their web page:
The 7.5 hours in the classroom are just the starting point. On average, teachers are at school an additional 90 minutes beyond the school day for mentoring, providing after-school help for students, attending staff meetings and collaborating with peers. Teachers then spend another 95 minutes at home grading, preparing classroom activities, and doing other job-related tasks. The workday is even longer for teachers who advise extracurricular clubs and coach sports —11 hours and 20 minutes, on average. As one Kentucky teacher surveyed put it, “Our work is never done. We take grading home, stay late, answer phone calls constantly, and lay awake thinking about how to change things to meet student needs.”
To my knowledge, the Board has never acknowledged this. In fact, they have previously attacked teachers for being overpaid while using only the contractually obligated work time as their measure. This extra time is no secret among teachers, and it's nothing new. Just doing the basic math for hand-grading a two-page report for 30 kids in one class can take a significant chunk of time from an English teacher; if you assume 5 minutes per report (which is an unrealistic deadline to begin with), it’s 150 minutes, or 2 hours and 30 minutes. For one class. What does the Board think is going on during that "self directed" time? Teacher disco hour?
It's at a point where the Board would have to be purposely playing stupid to not know how this factors in. The requirements put on teachers, with homework correction load and prep, makes accomplishing what needs to be complete within the time allotted a joke. It's as if you were tasked with moving a giant mound of sand from point A to point B; you are going to be paid to do it in an hour. The job has to get done, or you're fired and not paid for the job. But you will only be paid for an hour of work...even though it takes two hours to accomplish. Yet, teachers still accept this as part of the burden of working as a teacher even as the Board makes it abundantly clear that they're either clueless about what it takes to teach, or they simply enjoy making the work environment miserable.
It’s laughable that the Board insists they "...understand the importance of its professional staff to remain lifelong learners" before moving on to propose eliminating some salary benefits to continuing education along with a "if you leave within 4 years of tuition reimbursement you have to pay it back" and a cap on reimbursement spending. Does the Board not understand what they're saying there? "We know this is important. So we'd like to limit it in many ways, along with adding financial uncertainty by forcing you to pay back the education you're required to get if something happens where you leave our employ AND only some teachers can continue their education at a time.” How do you negotiate with this kind of cognitive dissonance?
Then they start winding down with some mini-zings, the bits that don't all seem to make much sense as points of contention unless they are actually put into context. Eliminating the transfer clause that allows seniority to be factored into filling vacant positions? What's the problem there? Not much, except it pretty much is meant to allow administrators and the Board to place favorite hires into new positions and add pressure to get rid of the expensive experienced teachers, assisting in eliminating positions by attrition (see the number of recent hires? Just speculating...)
Most of the Board's response (or "resposnse", which still makes me giggle) is disingenuous at best. They even claim, "There have been 2 independent fact finder reports completed in the last year. Both reports were rejected by the AAEA." Those unreasonable Union bastards!
 |
| Those unreasonable Union bastards...wait, what the hell? |
Um...that's kind of awkward. It pretty clearly says that the fact finder report was yet to be voted on by the Union for acceptance when the Board already rejected it. October 8 of 2015. Unanimously. It's available on the labor relations board website, by the way.
But if you were to just read the Board response, the rejection was all on the Union. Funny how a simple Google search shows that insinuation is utter crap.
The next page had a listing for an article from June 2014 when the board once again rejected a fact finder's report (and this one pointed out the teachers accepted the report.)
And for all the calls for saving money, the Board seems oddly bent on wasting money in other areas. For example, they recently spent $15,000 on a study that told them they were wasting $800,000 on transportation. There's bound to be some variability in spending...but $800,000? It's kind of an amazing article to read. And the report, too.
The Board is also cutting two checks to lawyers. This has a bill from John Audi (Sweet, Katz, & Williams) in January for nearly $6,000. (also one to a doctor, Sidney G. Ranck, Jr., for $1,200...he's in obstetrics and gynecology. That's kind of...disturbing?)
This bill has John Audi getting a check cut for nearly $3,000. And this one is another $6,500 check, along with their second lawyer, Pat Barrett, getting a check for $6,000. The list goes on.
And this is in addition to the acting superintendent's $130,000 salary (strange that seems to be missing from the salary list the Board is holding up as evidence that teachers are overpaid...)
The interesting part of that salary is that the previous superintendent was getting about $122,000/year. The acting superintendent isn't qualified to be superintendent and he's getting paid more. Part of me wonders if it's a gender thing...but that would be speculation. He's literally not qualified. The Board is paying for him to take classes and get his certification. That's why he's an acting superintendent. The previous superintendent was hired away from another district and had several years of experience. The new one is making more money and doesn't have a certificate. Somehow the Board equates this with hiring the best staff as per their resolutions back in January of 2013.
Overall the whole "response," in my opinion, is one long exercise in misleading the public. Take the claims that they have been open to bargaining this whole time in good faith with a grain of salt. They claim to care about the community and educating the kids, but their actions demonstrate, quite loudly, otherwise.
ADDENDUM
I did some quick checking of how much the frugal school board is spending on lawyer's fees. These figures were taken by eyeballing the board bills found on the school website. These reports are in PDF format, making them really really difficult to process in an automated fashion. Since I couldn't process them automatically I may have missed some payments, so the numbers I have, assuming I didn't misread some line items, would be considered a minimum paid to two law firms over the past 3 years, meaning there are probably payments missing. I think the contract talks may have extended beyond what bill items are on the website.
Regardless, this kind of money is interesting given how much the Board speaks of money problems and how expensive teachers are. It's also interesting how much vested interest the legal counsel has in prolonging the contract talks. How many meetings are there for negotiations? How much are they making per meeting?
The numbers are all there, listed with dates the checks were cut. Feel free to double check my numbers and tell me if I'm missing something. Also, I'm aware that the solicitor for the board (P.B.) does other duties, so these are not funds spent only on fighting the Union; I'm not privy to the other duties, however, so I can't break down the numbers into sub-categories. I've been told the John Audi firm was hired just to fight the Union, however, so big numbers are still big numbers.
Update 4-17-16
One of the sticking points in contract negotiations is in regards to the number of consecutive personal days a teacher may take. But it strikes me as being rather odd...what do they hope to accomplish by limiting consecutive personal days when teachers only get 3 personal days per year?
The AAEA (Union) provided an answer with a FaceBook post.
A Board member wanted to "talk" (usually situations like this implies "complain", but given a lack of specific information, that again is speculation) with a teacher. Teacher was on vacation. School board member now just happens to be pushing for limits on teacher time off.
If the implication is true the push to limit personal time off is purely for personal reasons, not for the benefit of the community taxpayers. This is a vendetta as a negotiations sticking point. How many other points of negotiation are driven by purely personal reasons?
Tuesday, December 23, 2014
Don't Be the Workplace Martyr (Because the Workplace Don't Care)
I was talking to someone recently who mentioned that they would be probably be working in the office over the weekend. Again. He had mentioned before having to work over past weekends. Maybe you've met this type of person before. They work weekends without pay or compensation. It has to be done for the good of the department or the company. He or she may also be the last one to leave the office most days of the week; there's always stuff to be done, and if they don't stay it's going to lead to some dire unspoken consequences.
I used to be like that. I worked in a school system where I didn't have to come in the weekends (thank $DEITY!) but I did stay late to finish things up. Oh, the sacrifice! I would stick around to work on things despite being on salary, sometimes looking down on the unionized staff in Maintenance or the office staff who, when break time came, they were off clock. If you approached them you were asking for an eye roll and they would speak to you in a voice that was so heavily burdened that you'd think you just threw their universe out of whack by speaking to them about something work-related.
I was dedicated. I was paid crap, compared to market rates. That's how the school was...it reinforced my sense of martyrdom. I was working hard for the intangible reasons. It made them respect me more, working for the good of the organization rather than the pay (because the pay was below market so I sure wasn't doing it for that...). I was reliable. I made us look better as a department. I was important as an asset to the organization. It made me a good person that others could look up to as an example.
I was clearly delusional.
Part of this was conflating my identity with my job, then further conflating my job with my employer. There have been recent articles discussing the importance of loving your job, but not your company, because you don't know when your company will stop loving you. And no one is so important that a company won't be able to function without you.
Working in the school, I didn't often see people leaving...mostly because the majority of employees in schools are both protected by unions (I wasn't) and they had contracts for set periods of time, so when they want to get rid of people they did it with more politicking than efficiency. And sometimes it was absolutely brutal; people would jockey to get a good position for themselves before gathering together to lament the people that weren't able to get into a position that wasn't eliminated or a department without forced retirements.
I left the last position after 11 years or so of service to that district. Despite the extra hours I had put in, there was no noise made for my departure. No goodbye party. No lunch thing. I remember my last act being placing my ID badge and keys on a table in what served as the makeshift server room and saying goodbye to myself one last time before shutting the lights off and walking away.
It really felt like no one gave a damn.
And you know what? They're still chugging along. They hired someone to fill my spot kind of quick (guess I was easily replaced) supposedly with a similar pay, despite me having to work a decade with a degree to my name to get that amount. I doubt anything I did had a lasting effect.
A decade of my life...working on some small projects here and there...extra time put in without extra pay...and it amounts to nothing.
(Side comment: it's no secret that a lack of overtime pay also hurts employees trying to get ahead financially...)
My current employer is great; they offer perks like free snacks and lunches, they buy employees the tech they need to get their job done rather than the decade of having to try to make outdated scraps into something half-usable, and they offer a Christmas bonus and present for employees. But as a company grows, they also have had people leave...the first time I had to deactivate accounts, I was greatly affected by it. I'd never had a situation where one day someone's there, the next I'm locking them out and the company kind of acts like they didn't exist.
But the company goes on. No one is irreplaceable.
There are still times where I will be there late. Sometimes I'm working on something. Usually because there's a couple of things I wanted to get done and got tired of having to push it to the next day. Other times I was doing something that took about %20 of my attention so I'd babysit the process (upgrading a system, installing some software, running an AV check...) while watching something on our super fast Internet connection while drinking something from the free drinky-fridge. If it was after what was reasonably considered working hours, anything coming in as a trouble ticket, unless it's dire, is considered kind of optional. My employer isn't a slave driver, I was doing it because I didn't have something more pressing to do.
There are also times (much less-so in my current department, more for SRE-related tasks) when you would have to work over the weekend. Usually this was for an alarm situation (something is really broken, or some dickhead script kiddie is home from school and has nothing better to do) or something big and scheduled like a data center move. Most cases these were scheduled or, in the case of being "on call," was done on a rotation.
My employer has been cognizant of the idea of "work-life balance."
My previous employer wasn't.
And that's where I was delusional. I let my job define me. Kind of like the old days, when you see a strong middle class family whose head of household was defined as a Xerox man or an IBM man. The company was your team, and they cared for you and provided for you and your family. Today, you're lucky if you keep the same job for more than 5 years.
Working on weekends, voluntarily, when your boss isn't expecting it of you and you aren't compensated, and you're doing it repeatedly...that's a sign that you need more people working with you. Or you don't know how to properly get work done in an allocated time. Either way is a failure condition.
To be clear: there are times when it's valid to sacrifice for your company. These times are infrequent, and you typically have some recognition or support for doing this with actual results. Or it makes your life easier because you're making up for time you were out during the typical workday. Situations vary.
But if you are doing it because you claim that you've been overwhelmed all week, and there's still a load of things to get done, you're possibly:
I used to be like that. I worked in a school system where I didn't have to come in the weekends (thank $DEITY!) but I did stay late to finish things up. Oh, the sacrifice! I would stick around to work on things despite being on salary, sometimes looking down on the unionized staff in Maintenance or the office staff who, when break time came, they were off clock. If you approached them you were asking for an eye roll and they would speak to you in a voice that was so heavily burdened that you'd think you just threw their universe out of whack by speaking to them about something work-related.
I was dedicated. I was paid crap, compared to market rates. That's how the school was...it reinforced my sense of martyrdom. I was working hard for the intangible reasons. It made them respect me more, working for the good of the organization rather than the pay (because the pay was below market so I sure wasn't doing it for that...). I was reliable. I made us look better as a department. I was important as an asset to the organization. It made me a good person that others could look up to as an example.
I was clearly delusional.
Part of this was conflating my identity with my job, then further conflating my job with my employer. There have been recent articles discussing the importance of loving your job, but not your company, because you don't know when your company will stop loving you. And no one is so important that a company won't be able to function without you.
Working in the school, I didn't often see people leaving...mostly because the majority of employees in schools are both protected by unions (I wasn't) and they had contracts for set periods of time, so when they want to get rid of people they did it with more politicking than efficiency. And sometimes it was absolutely brutal; people would jockey to get a good position for themselves before gathering together to lament the people that weren't able to get into a position that wasn't eliminated or a department without forced retirements.
I left the last position after 11 years or so of service to that district. Despite the extra hours I had put in, there was no noise made for my departure. No goodbye party. No lunch thing. I remember my last act being placing my ID badge and keys on a table in what served as the makeshift server room and saying goodbye to myself one last time before shutting the lights off and walking away.
It really felt like no one gave a damn.
And you know what? They're still chugging along. They hired someone to fill my spot kind of quick (guess I was easily replaced) supposedly with a similar pay, despite me having to work a decade with a degree to my name to get that amount. I doubt anything I did had a lasting effect.
A decade of my life...working on some small projects here and there...extra time put in without extra pay...and it amounts to nothing.
(Side comment: it's no secret that a lack of overtime pay also hurts employees trying to get ahead financially...)
My current employer is great; they offer perks like free snacks and lunches, they buy employees the tech they need to get their job done rather than the decade of having to try to make outdated scraps into something half-usable, and they offer a Christmas bonus and present for employees. But as a company grows, they also have had people leave...the first time I had to deactivate accounts, I was greatly affected by it. I'd never had a situation where one day someone's there, the next I'm locking them out and the company kind of acts like they didn't exist.
But the company goes on. No one is irreplaceable.
There are still times where I will be there late. Sometimes I'm working on something. Usually because there's a couple of things I wanted to get done and got tired of having to push it to the next day. Other times I was doing something that took about %20 of my attention so I'd babysit the process (upgrading a system, installing some software, running an AV check...) while watching something on our super fast Internet connection while drinking something from the free drinky-fridge. If it was after what was reasonably considered working hours, anything coming in as a trouble ticket, unless it's dire, is considered kind of optional. My employer isn't a slave driver, I was doing it because I didn't have something more pressing to do.
There are also times (much less-so in my current department, more for SRE-related tasks) when you would have to work over the weekend. Usually this was for an alarm situation (something is really broken, or some dickhead script kiddie is home from school and has nothing better to do) or something big and scheduled like a data center move. Most cases these were scheduled or, in the case of being "on call," was done on a rotation.
My employer has been cognizant of the idea of "work-life balance."
My previous employer wasn't.
And that's where I was delusional. I let my job define me. Kind of like the old days, when you see a strong middle class family whose head of household was defined as a Xerox man or an IBM man. The company was your team, and they cared for you and provided for you and your family. Today, you're lucky if you keep the same job for more than 5 years.
Working on weekends, voluntarily, when your boss isn't expecting it of you and you aren't compensated, and you're doing it repeatedly...that's a sign that you need more people working with you. Or you don't know how to properly get work done in an allocated time. Either way is a failure condition.
To be clear: there are times when it's valid to sacrifice for your company. These times are infrequent, and you typically have some recognition or support for doing this with actual results. Or it makes your life easier because you're making up for time you were out during the typical workday. Situations vary.
But if you are doing it because you claim that you've been overwhelmed all week, and there's still a load of things to get done, you're possibly:
- Overloaded. The company/organization needs to hire someone to help with the workload.
- Disorganized, and can't get things done efficiently enough to keep up.
- Being taken advantage of. After all, you're paid to work X hours. If you don't get overtime, you're giving work for free, and that devalues you and your skills (unless you're somehow compensated by owning part of the company...)
- Asking to be taken advantage of. Hey, you work extra for free? Soon it goes from being an occasional thing to an expectation. Don't be shocked. You conditioned others to treat you that way.
I've seen other people in situations where they worked their asses off for an organization, only to become embittered when they leave and the organization doesn't really care. Those people tied their identities to that employer, then were shocked to discover that their extra work in the practical sense meant very little. They were just another cog that was quickly replaced.
I fell for that delusion and I try not to anymore. The extra work I do...usually tying up loose ends at the end of the workday...isn't because I have to do it. Rarely am I swearing at the expectation of putting in extra uncompensated time. Because I understand that I need to do something with a little more meaning that will also outlast me, since at any time my employer can terminate my professional relationship.
For the most part I think my attitude has reached a healthy balance between "I want my boss to like me and I really love my job" and the people who I grew irritated with when I was trying to get something done and, for example, needed a door unlocked only to find staff in a lounge staring at the clock because "IT'S BREAKTIME WHY ARE YOU TALKING TO ME?!"
I'd like to think my employer likes me. I'd like to think I do a satisfactory job for them, and that they appreciate what help I can offer to other employees. But in the end I am me. I work for an employer. And I am not the company. You would do well to find that separation as well, for your own work/life balance and sanity. Maybe that's part of what happens as you get older...it's part of growing up and seeing the world with less optimistic lenses.
Tuesday, October 7, 2014
What I Learned About Functional Specs And Mockups
We've been having discussion in our department regarding workflow, communication, and automation. There came a point in these discussions where I described a system that I thought would make things simpler for us as a group with an interface that we and new hires alike would find useful.
I thought I was describing it eloquently. But then again, I knew what I was describing.
But there are other practical obstacles to communicating such ideas. For example, your team may feel they have better things to think about. Maybe they are biased towards their own ideas, or that this is a waste of time because dammit the current system works fine if only you weren't whining so much, or whatever their mind has wandered off to at that point of the meeting.
In the end the boss decided to steer the meeting by relenting to a "write something up and work with <coworker> on this, we'll discuss it after that" approach.
I should back up a little bit here...I'd grumbled about a lack of documentation on the state of the in-house project growing in our department for awhile, but because grumbling isn't seen as productive, I felt the concerns were dismissed. What I later understood was it wasn't a lack of documentation so much as a lack of a functional specification. Others on the team didn't understand the problem until we were in a meeting and three people had three totally different ideas on how the system did something. Because the application was in a functional state, there wasn't a problem seen. It was doing things, right? No alarm bells, nothing broken...move fast and break things then fix them later. Whiners were just falling behind.
Observation One: Functional specs aren't necessary to have a "working" system, but they can keep people on the same page.
Maybe that works until it dawns on everyone that what they know is wrong.
"But you're not describing a functional spec," you might say. "How a system does things is a technical spec!"
That's true, but sometimes the how something works affects the user interface and interaction...in this case there are ways of doing things that the system may mysteriously change behind your back without notice. That's an interface interaction that ideally is covered in both a technical and functional spec. The proper workflow should be baked into the functional spec.
The immediate reaction...thinking this is a documentation issue...was to have people document how the system worked. Which isn't bad to have for reference. But it's a band-aid; a reaction rather than pro action. Reading it didn't give me a sense of what the end product was going to do or how it would fully address the future integration of automation...it was a snapshot of what had already been done.
In a way, it was kind of a postmortem.
Observation Two: Documentation is a blanket term with many sub-categories. Sometimes you have to identify what kind of documentation is missing before identifying that as a problem.
I spent some time reading up on functional specs and pondering how I would approach the problem. Turned out I knew someone who had written some nice introductory material on functional specs freely available on the Internet.
At its heart a functional spec is a description of how an application is expected to work with the users. It describes, in detail, how the application works with the user.
I then started writing. You would think this is easy. You would be wrong. Maybe if you have a really clear idea of every bit of the proposed application in your head coupled with experience in writing specs, you'll find the task easy. Chances are you'll find that clear idea of how you want to interact with and configure the system is just a set of highlights you expect in a working system. You don't realize the number of things you just don't think about or take for granted in a system that a decent spec calls for you to spell out. ("Oh...yeah...logout button? Or a logout link? Is it in a menu?")
Observation Three: The Functional Spec was longer than I thought it would be.
This was a relatively simple web application, or so I thought. Then I started describing the pages I had in mind.
One thing led to another which led to another. It didn't take long for the first draft to hit 15 pages.
Observation Four: Mockups make specs come to life, and bring out glaring errors.
I thought the mockup was best for presentation purposes. The spec tutorials heavily rely on humor for keeping people engaged enough to slog through the details of what I think a website should look like. As you can guess, I'm not really entertaining enough to keep my team reading my proposal.
A mockup, however, is a picture worth thousands of words. After I completed my first draft of a spec, I pulled out a copy of a mockup application called Balsamiq. I had never used it before and dreaded the learning curve; fortunately, the fears were largely over nothing. It wasn't long before I had the initial pages staged.
I also discovered several places where my descriptions, so clear and useable in my head, were simply impractical or felt wrong once they were applied on the mockup. In other places I discovered redundancies in function that overcomplicated the workflow. Trying to map this in my head from words on the page didn't quite work; the pictures illustrated what turned out to be glaring errors, and when I went back to the page on the spec, the errors on the written page were such that I could not unsee them. Doh!
Other times I discovered ways of doing things better on the mockup that didn't occur to me on the written spec. More notes were scribbled down for future reference.
Observation Five: A good mockup program can make a good presentation tool.
Mockups are new territory for me. I never had a job where spending time on a mockup of an application would be potentially useful. It turns out that Balsamiq is more than Powerpoint for interfaces.
I discovered that this program allows for linking pages together, a natural display of features for mocking up a web application. I can also export the pages to PDF and it looks like those PDFs will be interlinked as I set up the mockup project. Balsamiq also allows for the use of comment notes that can be hidden, describing features and workflow within the mockup itself. If my functional spec weren't so wordy, and if there weren't some features and description that aren't really illustrated in the mockup, I'd be tempted to just dump the functional spec text into a series of comments in the mockup and forego the use of the separate functional spec altogether.
Observation Six: The mockup has given me more notes for the rewrite of the spec.
Aw, dammit...more writing.
The first draft of the spec was a page-by-page description of the web application. After seeing the pages illustrated, I now have many notes scribbled on post-its and in the margins of a printed copy of the spec. Now I have to go back and re-write parts of the spec.
The first draft isn't horrible, if I do say so myself. But it if I am to present this to the team, it needs to have I's dotted and T's crossed, and it needs to be in line with the mockup.
There will no doubt be mistakes. That's no excuse to not try fixing errors.
Observation Seven: Order of dependencies matter, as does the ability to reference information in the spec.
This is something I learned about in a Ruby talk about communicating with developers. It's meant to be a good practice for giving presentations, but I think it also makes sense in certain types of writing.
In a technical description, you should not have a dependency on something later.
That is to say, if you're talking about something technical, you should avoid whenever possible a situation where you describe something but "if you don't understand X, it's okay, we'll get to that in a bit." I'm sure you've run into that before; I know I've heard it. In the talk, the presenter said that he's given his thesis statement, the most important bit of information, as a "header" to the discussion. If the attendee fell asleep at some point in the talk, he would already know the idea that the presenter thought was most important, and in the process of the talk there were little to no loose ends.
As I go back through the spec I'm going to try keeping an eye on my descriptions to see if they need to be rearranged a bit for clarity. I'll bake in descriptions when necessary and minimize references to other spots in the spec; that way if I eliminate sections or change how something on a page works it won't make another spot reference a non-existing bit of information.
I'm also going to try making the spec referenced with a table of contents, so pages and sections can be quickly searched even if printed. A spec is a living document. If you can't easily navigate it as it grows, it won't be useful.
Observation Eight: Specs and mockups can become a skeleton of a user manual.
The more I wrote and the more I illustrated, the more I saw the beginnings of a user manual for an application take shape. It makes sense...if a functional spec outlines how a user is supposed to interact with your application, and it describes the expected behavior of the application, well...that's the basics of user documentation.
This documentation...proto-user-manual...not only takes care of the initial design work that goes into the application, but also takes care of the initial steps for the dreaded technical writing involved in documenting how things work! Two birds, one stone! As long as it's kept up to date, that is.
I harbor no illusion that this work will not be for naught. This is a proposal for something that may never see the light of day. And while specs are not fun for most people, I'm finding that the work that goes into the initial stages of planning the application can be rewarding. It's quite a mental exercise to map out an application in your head, try to communicate that to the written word, translate the written word into a mockup, and then refine the written word again.
Even the tutorial for specs pointed out how often this step...the functional spec...is skipped. People like to jump right into coding in some kind of shoot-from-the-hip coding style and fix issues as they crop up. But after trying my hand at my first attempt at a spec, I wonder if spec writing and review is akin to the lack of respect for editors in print news; the industry knows they can cut editors and still have a product to churn out, and they justify it by citing the speed of their competitor, the "Internet," with which they're competing.
They completely ignore the number of glaring errors and botched headlines that slip through. And poor quality writing. The difference between a good editor's refinement of a news story and the shoveled crap that makes its way to print is the difference between a showman's presentation like Steve Jobs' Apple events and those painful talks where every third syllable on stage is an "um."
Another point; how much time is lost having to re-code for errors or changes that would have been caught had it been properly spec'd in the first place?
But those are speculation and opinion. I still have work to do...several more pages to be mocked up and then the second draft to work on. The hard part is squirreling away the blocks of time to work on them. The surprising part is that I'm actually enjoying the process!
I thought I was describing it eloquently. But then again, I knew what I was describing.
But there are other practical obstacles to communicating such ideas. For example, your team may feel they have better things to think about. Maybe they are biased towards their own ideas, or that this is a waste of time because dammit the current system works fine if only you weren't whining so much, or whatever their mind has wandered off to at that point of the meeting.
In the end the boss decided to steer the meeting by relenting to a "write something up and work with <coworker> on this, we'll discuss it after that" approach.
I should back up a little bit here...I'd grumbled about a lack of documentation on the state of the in-house project growing in our department for awhile, but because grumbling isn't seen as productive, I felt the concerns were dismissed. What I later understood was it wasn't a lack of documentation so much as a lack of a functional specification. Others on the team didn't understand the problem until we were in a meeting and three people had three totally different ideas on how the system did something. Because the application was in a functional state, there wasn't a problem seen. It was doing things, right? No alarm bells, nothing broken...move fast and break things then fix them later. Whiners were just falling behind.
Observation One: Functional specs aren't necessary to have a "working" system, but they can keep people on the same page.
Maybe that works until it dawns on everyone that what they know is wrong.
"But you're not describing a functional spec," you might say. "How a system does things is a technical spec!"
That's true, but sometimes the how something works affects the user interface and interaction...in this case there are ways of doing things that the system may mysteriously change behind your back without notice. That's an interface interaction that ideally is covered in both a technical and functional spec. The proper workflow should be baked into the functional spec.
The immediate reaction...thinking this is a documentation issue...was to have people document how the system worked. Which isn't bad to have for reference. But it's a band-aid; a reaction rather than pro action. Reading it didn't give me a sense of what the end product was going to do or how it would fully address the future integration of automation...it was a snapshot of what had already been done.
In a way, it was kind of a postmortem.
Observation Two: Documentation is a blanket term with many sub-categories. Sometimes you have to identify what kind of documentation is missing before identifying that as a problem.
I spent some time reading up on functional specs and pondering how I would approach the problem. Turned out I knew someone who had written some nice introductory material on functional specs freely available on the Internet.
At its heart a functional spec is a description of how an application is expected to work with the users. It describes, in detail, how the application works with the user.
I then started writing. You would think this is easy. You would be wrong. Maybe if you have a really clear idea of every bit of the proposed application in your head coupled with experience in writing specs, you'll find the task easy. Chances are you'll find that clear idea of how you want to interact with and configure the system is just a set of highlights you expect in a working system. You don't realize the number of things you just don't think about or take for granted in a system that a decent spec calls for you to spell out. ("Oh...yeah...logout button? Or a logout link? Is it in a menu?")
Observation Three: The Functional Spec was longer than I thought it would be.
This was a relatively simple web application, or so I thought. Then I started describing the pages I had in mind.
One thing led to another which led to another. It didn't take long for the first draft to hit 15 pages.
Observation Four: Mockups make specs come to life, and bring out glaring errors.
I thought the mockup was best for presentation purposes. The spec tutorials heavily rely on humor for keeping people engaged enough to slog through the details of what I think a website should look like. As you can guess, I'm not really entertaining enough to keep my team reading my proposal.
A mockup, however, is a picture worth thousands of words. After I completed my first draft of a spec, I pulled out a copy of a mockup application called Balsamiq. I had never used it before and dreaded the learning curve; fortunately, the fears were largely over nothing. It wasn't long before I had the initial pages staged.
I also discovered several places where my descriptions, so clear and useable in my head, were simply impractical or felt wrong once they were applied on the mockup. In other places I discovered redundancies in function that overcomplicated the workflow. Trying to map this in my head from words on the page didn't quite work; the pictures illustrated what turned out to be glaring errors, and when I went back to the page on the spec, the errors on the written page were such that I could not unsee them. Doh!
Other times I discovered ways of doing things better on the mockup that didn't occur to me on the written spec. More notes were scribbled down for future reference.
Observation Five: A good mockup program can make a good presentation tool.
Mockups are new territory for me. I never had a job where spending time on a mockup of an application would be potentially useful. It turns out that Balsamiq is more than Powerpoint for interfaces.
I discovered that this program allows for linking pages together, a natural display of features for mocking up a web application. I can also export the pages to PDF and it looks like those PDFs will be interlinked as I set up the mockup project. Balsamiq also allows for the use of comment notes that can be hidden, describing features and workflow within the mockup itself. If my functional spec weren't so wordy, and if there weren't some features and description that aren't really illustrated in the mockup, I'd be tempted to just dump the functional spec text into a series of comments in the mockup and forego the use of the separate functional spec altogether.
Observation Six: The mockup has given me more notes for the rewrite of the spec.
Aw, dammit...more writing.
The first draft of the spec was a page-by-page description of the web application. After seeing the pages illustrated, I now have many notes scribbled on post-its and in the margins of a printed copy of the spec. Now I have to go back and re-write parts of the spec.
The first draft isn't horrible, if I do say so myself. But it if I am to present this to the team, it needs to have I's dotted and T's crossed, and it needs to be in line with the mockup.
There will no doubt be mistakes. That's no excuse to not try fixing errors.
Observation Seven: Order of dependencies matter, as does the ability to reference information in the spec.
This is something I learned about in a Ruby talk about communicating with developers. It's meant to be a good practice for giving presentations, but I think it also makes sense in certain types of writing.
In a technical description, you should not have a dependency on something later.
That is to say, if you're talking about something technical, you should avoid whenever possible a situation where you describe something but "if you don't understand X, it's okay, we'll get to that in a bit." I'm sure you've run into that before; I know I've heard it. In the talk, the presenter said that he's given his thesis statement, the most important bit of information, as a "header" to the discussion. If the attendee fell asleep at some point in the talk, he would already know the idea that the presenter thought was most important, and in the process of the talk there were little to no loose ends.
As I go back through the spec I'm going to try keeping an eye on my descriptions to see if they need to be rearranged a bit for clarity. I'll bake in descriptions when necessary and minimize references to other spots in the spec; that way if I eliminate sections or change how something on a page works it won't make another spot reference a non-existing bit of information.
I'm also going to try making the spec referenced with a table of contents, so pages and sections can be quickly searched even if printed. A spec is a living document. If you can't easily navigate it as it grows, it won't be useful.
Observation Eight: Specs and mockups can become a skeleton of a user manual.
The more I wrote and the more I illustrated, the more I saw the beginnings of a user manual for an application take shape. It makes sense...if a functional spec outlines how a user is supposed to interact with your application, and it describes the expected behavior of the application, well...that's the basics of user documentation.
This documentation...proto-user-manual...not only takes care of the initial design work that goes into the application, but also takes care of the initial steps for the dreaded technical writing involved in documenting how things work! Two birds, one stone! As long as it's kept up to date, that is.
I harbor no illusion that this work will not be for naught. This is a proposal for something that may never see the light of day. And while specs are not fun for most people, I'm finding that the work that goes into the initial stages of planning the application can be rewarding. It's quite a mental exercise to map out an application in your head, try to communicate that to the written word, translate the written word into a mockup, and then refine the written word again.
Even the tutorial for specs pointed out how often this step...the functional spec...is skipped. People like to jump right into coding in some kind of shoot-from-the-hip coding style and fix issues as they crop up. But after trying my hand at my first attempt at a spec, I wonder if spec writing and review is akin to the lack of respect for editors in print news; the industry knows they can cut editors and still have a product to churn out, and they justify it by citing the speed of their competitor, the "Internet," with which they're competing.
They completely ignore the number of glaring errors and botched headlines that slip through. And poor quality writing. The difference between a good editor's refinement of a news story and the shoveled crap that makes its way to print is the difference between a showman's presentation like Steve Jobs' Apple events and those painful talks where every third syllable on stage is an "um."
Another point; how much time is lost having to re-code for errors or changes that would have been caught had it been properly spec'd in the first place?
But those are speculation and opinion. I still have work to do...several more pages to be mocked up and then the second draft to work on. The hard part is squirreling away the blocks of time to work on them. The surprising part is that I'm actually enjoying the process!
Posted with BlogsySunday, January 26, 2014
Pattern Blindness
The mind is a strange thing. It has so many coping mechanisms, as well as an ability to make itself blind to them. Sometimes you'll experience a flash of insight that makes you wonder how you could have missed it.
Think for a moment about something like a billboard. We ended up getting more of them back home. When it was novelty-new I heard the occasional gripe about the way the billboards cluttered up the view as people drove into town. Soon enough the discussions died down. A few short years later they barely register as I enter the town limits. Unless the message is really something eye-catching, it's like they're not even there. They've become visual static, noise that doesn't annoy or provoke brand awareness or an urge to purchase anything. Except perhaps the one that went up for the restaurant in a local casino, wherein the image the advertisers used is a waitress with looming 15-foot circumference boobs over the road. That does tend to draw the eye a bit more than something advertising a local bank with an awkward smile of a VP glaring at you in a creepy manner.
At work we have the honor of hearing all sorts of fire alarm tests. We've been hearing them for months. I'm not sure what they're testing for, but I do know that no one listens to them anymore. Just the other day I had my headphones on in my office when the garbled, staticky Peanuts-adult voice started belching from the speakers on the floor. At this point we just assume that unintelligible mess is a prelude to the wails of another alarm, and sure enough, the alarms go off. I don't think any employees pay attention anymore. Unless there is actual smoke and flames in sight, I'm pretty sure we're going to die from toxic gas buildup if there is an actual fire emergency. The constant annoying "tests" have made us immune to the alarm and announcements. It's static. Background noise.
What I'm trying to say is that when you get bombarded with similar stimuli all the time, the brain creates a kind of filter to make you numb to that stimuli. The only way to break through that awareness shield is to intentionally stop and analyze the situation, forcibly stripping the barriers your own brain put in place to protect you from overloading your senses with cruft and whatever is being sold on billboards.
How is this relevant to working in IT or programming? I have this theory that your brain makes certain assumptions based on experiences as to what should and shouldn't be filtered. You stop paying attention to the noise and instead look for the novel. Sometimes you experience the same problems enough that you learn to no longer pay attention to them, and in the process project them into the world at large. As if they learn and filter out the obvious as a source of problems. The obvious, though, is only obvious to you, and classified by your brain as a source of static to be selectively blinded from you.
This means that even though diagnosing a problem may be something elementary, because you have experienced it so many times that the repetition has made it the source of jokes, you may reach a point where you overlook the obvious because part of your brain tries jumping to the novel rather than the simple "most likely" cause. Sometimes you have to stop and reset your brain to see things from the beginning of the troubleshooting tree because it just doesn't want to check that the damn thing is plugged in.
Perspective. The best weapon against the brain's self-delusion coping mechanism.
Think for a moment about something like a billboard. We ended up getting more of them back home. When it was novelty-new I heard the occasional gripe about the way the billboards cluttered up the view as people drove into town. Soon enough the discussions died down. A few short years later they barely register as I enter the town limits. Unless the message is really something eye-catching, it's like they're not even there. They've become visual static, noise that doesn't annoy or provoke brand awareness or an urge to purchase anything. Except perhaps the one that went up for the restaurant in a local casino, wherein the image the advertisers used is a waitress with looming 15-foot circumference boobs over the road. That does tend to draw the eye a bit more than something advertising a local bank with an awkward smile of a VP glaring at you in a creepy manner.
At work we have the honor of hearing all sorts of fire alarm tests. We've been hearing them for months. I'm not sure what they're testing for, but I do know that no one listens to them anymore. Just the other day I had my headphones on in my office when the garbled, staticky Peanuts-adult voice started belching from the speakers on the floor. At this point we just assume that unintelligible mess is a prelude to the wails of another alarm, and sure enough, the alarms go off. I don't think any employees pay attention anymore. Unless there is actual smoke and flames in sight, I'm pretty sure we're going to die from toxic gas buildup if there is an actual fire emergency. The constant annoying "tests" have made us immune to the alarm and announcements. It's static. Background noise.
What I'm trying to say is that when you get bombarded with similar stimuli all the time, the brain creates a kind of filter to make you numb to that stimuli. The only way to break through that awareness shield is to intentionally stop and analyze the situation, forcibly stripping the barriers your own brain put in place to protect you from overloading your senses with cruft and whatever is being sold on billboards.
How is this relevant to working in IT or programming? I have this theory that your brain makes certain assumptions based on experiences as to what should and shouldn't be filtered. You stop paying attention to the noise and instead look for the novel. Sometimes you experience the same problems enough that you learn to no longer pay attention to them, and in the process project them into the world at large. As if they learn and filter out the obvious as a source of problems. The obvious, though, is only obvious to you, and classified by your brain as a source of static to be selectively blinded from you.
This means that even though diagnosing a problem may be something elementary, because you have experienced it so many times that the repetition has made it the source of jokes, you may reach a point where you overlook the obvious because part of your brain tries jumping to the novel rather than the simple "most likely" cause. Sometimes you have to stop and reset your brain to see things from the beginning of the troubleshooting tree because it just doesn't want to check that the damn thing is plugged in.
Perspective. The best weapon against the brain's self-delusion coping mechanism.
Monday, January 13, 2014
On The Importance of Vulnerability (And A Culture That Accepts It)
I came from a job that had several toxic aspects.
Of course if you talk to people running the system, they probably wouldn't see it that way. They may deny it. But in truth, there was always a series of elements that mixed together that seemed to undermine a person's confidence in themselves, in their abilities, and in their value as people.
It was an environment that, in some ways, crushed your soul.
Perhaps this is, to a degree, retrospective retconning. Perhaps this was all in my head. Perhaps I have a personality that actively seeks validation, and that job was one where I didn't get enough of it to feel as if I were needed in any valuable way. But this was...is...how I feel about that environment. I've found little evidence to dispute that perception.
But the purpose of this isn't to complain about the past. I bring it up to help segue into my present; a present where I was recently telling my manager that I still feel haunted by the feeling that I am waiting for the other shoe to drop or that I'm being set up for failure. These are feelings that I own up to and struggle with when I feel the urge to take the initiative on an issue or when I'm contemplating questions like, "Where do you want to go professionally in the coming months (or years?)"
That background contributed to my sense of awe when I came to work for my current employer, and the paradoxical feeling of inadequacy when in the presence of these professional giants. I mean, many of my new coworkers have companies on the side, or programming projects that are helping people in the real world outside the company. The head of the company travels the world giving speeches and can drive twitter traffic with a mere mention of a site. I work with smart people who have established popular credibility in the outside world, while my little blog is meaningless; the truth is that in all likelihood I could say horrible things while naming names and the people and businesses I talk about would probably never know it.
Of course the longer I work in this environment the more I see the cracks in my projected sainthood delusions I imposed on these people revealing the flawed human beings underneath. I'm not complaining. It's simply a matter of acclimating. And for someone with a severe inadequacy complex, it's also a relief.
Recently a coworker whom I hold in high esteem was shocked to learn that ports on Unix-like systems are treated differently, depending on the port number. See, due to outdated security models, ports below 1024 need root access if you want to bind to them. It's a legacy thing that is of little use today but still sticks around to act as an irritating hazing for new admins, I guess.
But the coworker, with a great number of years of experience under his belt as a programmer, didn't know that. And I was surprised to know that he didn't, as I kind of assumed...as people with imposter syndrome are wont to do...that he knew this.
Of course he knew that. I knew it. I didn't just know it, I knew it like "give a look of incredulity if any tech person asked me about it because they should already know this information" kind of know it. But he didn't know it. And he let people know he didn't know it, like it was a strange gem of trivia. He was all, "Hey, did you guys know this? That's weird!," waving this flag of not knowing like a child discovering gummy bears for the first time.
He was someone I had on a pedestal. Still do. He's very good at what he does. But for once I felt I knew something that could be useful to one of these people. I try to contribute every day in some way; sometimes I feel I succeed, other times I don't. Sometimes I feel like I just can't. Being on the low end of the usefulness totem pole is a rough headspace to be in.
The point is that it's good to have people who are good at what they do screw up sometimes, and it's good to show that it's okay to not know something. It's good to show a vulnerability. Because maybe they, in a way, are leaders. Or examples. Other people hold them in esteem. And sometimes if they're on too high of a pedestal it feels to these admirers that their idols are unreachable; they aren't human so much as the embodiment of an unreachable ideal. Seeing their human side (and working in a company culture that accepts and embraces those flaws) means that yes, you can aspire to be more like them and perhaps become skilled like them.
You know...if I may nerd out for a few moments...there are people who look up to Superman. They aspire to live to his ideals, the embodiment of what is good in people. But no one thinks they could ever be Superman. He's not human. He's basically a god. A big, bulletproof god that is apparently doing well for himself financially despite working for a newspaper in this economy.
But Batman...you could, technically, train yourself for years to reach the pinnacle of physical fitness and become something close to Batman. There's a fraction of a percent of a chance that you'd do it. But in the back of your mind you know he's a regular human with no superpowers that can kick just about any bad guy's ass using a combination of intellect, skill and physical training. You can't train yourself to be a sun-absorbing alien able to lift trains, but you could become the peak-of-human-limits athlete in an armored suit.
When you are in a position where someone may look up to you as a mentor figure, it's good to be more a Batman and less a Superman.
Of course if you talk to people running the system, they probably wouldn't see it that way. They may deny it. But in truth, there was always a series of elements that mixed together that seemed to undermine a person's confidence in themselves, in their abilities, and in their value as people.
It was an environment that, in some ways, crushed your soul.
Perhaps this is, to a degree, retrospective retconning. Perhaps this was all in my head. Perhaps I have a personality that actively seeks validation, and that job was one where I didn't get enough of it to feel as if I were needed in any valuable way. But this was...is...how I feel about that environment. I've found little evidence to dispute that perception.
But the purpose of this isn't to complain about the past. I bring it up to help segue into my present; a present where I was recently telling my manager that I still feel haunted by the feeling that I am waiting for the other shoe to drop or that I'm being set up for failure. These are feelings that I own up to and struggle with when I feel the urge to take the initiative on an issue or when I'm contemplating questions like, "Where do you want to go professionally in the coming months (or years?)"
That background contributed to my sense of awe when I came to work for my current employer, and the paradoxical feeling of inadequacy when in the presence of these professional giants. I mean, many of my new coworkers have companies on the side, or programming projects that are helping people in the real world outside the company. The head of the company travels the world giving speeches and can drive twitter traffic with a mere mention of a site. I work with smart people who have established popular credibility in the outside world, while my little blog is meaningless; the truth is that in all likelihood I could say horrible things while naming names and the people and businesses I talk about would probably never know it.
Of course the longer I work in this environment the more I see the cracks in my projected sainthood delusions I imposed on these people revealing the flawed human beings underneath. I'm not complaining. It's simply a matter of acclimating. And for someone with a severe inadequacy complex, it's also a relief.
Recently a coworker whom I hold in high esteem was shocked to learn that ports on Unix-like systems are treated differently, depending on the port number. See, due to outdated security models, ports below 1024 need root access if you want to bind to them. It's a legacy thing that is of little use today but still sticks around to act as an irritating hazing for new admins, I guess.
But the coworker, with a great number of years of experience under his belt as a programmer, didn't know that. And I was surprised to know that he didn't, as I kind of assumed...as people with imposter syndrome are wont to do...that he knew this.
Of course he knew that. I knew it. I didn't just know it, I knew it like "give a look of incredulity if any tech person asked me about it because they should already know this information" kind of know it. But he didn't know it. And he let people know he didn't know it, like it was a strange gem of trivia. He was all, "Hey, did you guys know this? That's weird!," waving this flag of not knowing like a child discovering gummy bears for the first time.
He was someone I had on a pedestal. Still do. He's very good at what he does. But for once I felt I knew something that could be useful to one of these people. I try to contribute every day in some way; sometimes I feel I succeed, other times I don't. Sometimes I feel like I just can't. Being on the low end of the usefulness totem pole is a rough headspace to be in.
The point is that it's good to have people who are good at what they do screw up sometimes, and it's good to show that it's okay to not know something. It's good to show a vulnerability. Because maybe they, in a way, are leaders. Or examples. Other people hold them in esteem. And sometimes if they're on too high of a pedestal it feels to these admirers that their idols are unreachable; they aren't human so much as the embodiment of an unreachable ideal. Seeing their human side (and working in a company culture that accepts and embraces those flaws) means that yes, you can aspire to be more like them and perhaps become skilled like them.
You know...if I may nerd out for a few moments...there are people who look up to Superman. They aspire to live to his ideals, the embodiment of what is good in people. But no one thinks they could ever be Superman. He's not human. He's basically a god. A big, bulletproof god that is apparently doing well for himself financially despite working for a newspaper in this economy.
But Batman...you could, technically, train yourself for years to reach the pinnacle of physical fitness and become something close to Batman. There's a fraction of a percent of a chance that you'd do it. But in the back of your mind you know he's a regular human with no superpowers that can kick just about any bad guy's ass using a combination of intellect, skill and physical training. You can't train yourself to be a sun-absorbing alien able to lift trains, but you could become the peak-of-human-limits athlete in an armored suit.
When you are in a position where someone may look up to you as a mentor figure, it's good to be more a Batman and less a Superman.
Thursday, August 29, 2013
It's Been a Year
I started working at StackExchange a little over a year ago. I was reminded of this when I realized yearly evaluations are fast approaching...a time when our work and personal growth would be examined to see how our careers are coming along.
This also marks the slightly-over-a-year anniversary of my first day at StackExchange. My first day was July 9th, 2012. I was terrified.
I suppose it isn't out of the ordinary for new hires to have the jitters. But for me, I think it was a little worse than average. I had literally uprooted from my home in rural PA only three days before, moving into a small apartment during what became some of the hottest weather that summer. I was still learning how to navigate the subway system and not familiar with finding the office building once I emerged from the underground labyrinth, and all the stories about mugging and robberies were dancing in my head.
...and that was just the challenge of showing up the first day.
Once there, I had to confront my own demons. Imposter syndrome, I suppose it's called. I had in part tried for this job...a job that I initially didn't get, adding to the pressure to make a decent impression...because it was co-founded by Joel Spolsky, who had an established track record as a leader in the business of software. StackExchange was a growing startup and this certified Internet celebrity had a desk fifteen feet away from my door. To say I find this intimidating is an understatement.
But Joel (or Jo-El of the planet Krypton, as he once quipped on an internal communication...one of several fond memories of the past year and one that illustrated that he was actually human, I think...) wasn't the only perceived job intimidation. StackExchange hires crazy smart programmers. I've always wondered if I had a talent for programming...a what-if scenario where if things had been only slightly different, could I have been successful as a programmer?
To even entertain the idea seemed preposterous. I would be starting from near scratch, since my software projects have been simple and of course atrocious; a simple system for managing user management and log checking at the ISP I was employed with and a few VB projects at the school where I was a sysadmin after that. The college project didn't even use proper error checking to sanitize input, although I at least acknowledged the security issues in my documentation.
But there were times I would write down ideas and read about creating a software startup. My shelves have several books on software engineering and succeeding in small business...so there was always a spark of an idea that never quite caught fire.
Now I'd be working with professionals...as in people I could never bring myself to show my own samples of yesteryear to for fear they'd question how I was hired. Their casual code slinging was yet another source of intimidation I had to overcome. In addition, some of them have software businesses on the side like GoRead and Alikewise.com.
I think there were times David and Kyle felt bad for me when my confidence would flounder. Sometimes.
Gradually I grew out of much of the intimidation and imposter syndrome. Not all of it; I still can't stop the wave of anxiety that hits when I'm near the big boss, fearing I'll do something to make a fool of myself or offend him. But I can approach the programmers' den without feeling that my presence is only tolerated.
Limiting the extent to which I doubted my own competence wasn't the only improvement. I spent much of the past year learning how things work, doing things the StackExchange way. It turns out that isn't easy in a startup when the policies and procedures are in flux. You have to learn how things are gone as well as why they are done that way; then you transition into influencing policies and procedures related to your field. I managed to do that. I'm actively refining our on boarding procedures for new employees and configuring their systems.
I even managed to add a little competence in Cisco. I track down systems on the network using MAC addresses and reconfigure drops to limit access to particular VLANs without supervision anymore...I know, I should have been able to do that sooner. In my previous jobs I didn't need to do it. We rarely had need to reconfigure what gear we had, and when we did, much of it was outsourced to a contractor. We were plenty busy without dealing with that. Now I'm making changes on switches where if something goes south, it'll cost us money and productivity.
Overall much of this year was managing to get my footing. Learning how things are done. And from there finding my niches.
I may someday get into video work; we can host presentations in our lunchroom space, and one time we hosted a talk when our primary AV person was, at the time, on a plane. I was flying solo with the equipment. The presentation went fairly well, and I went through the video to clean it up a bit (and obscure a slip of personal information during the show.) I really enjoyed doing that, as strange as it may sound. A sysadmin that plays with video? Well, I did minor in theater in college, after all. It shouldn't be THAT much of a surprise.
I met the founder of Wikipedia. Thanks to StackExchange, WikiMedia gave the company one ticket to see the Colbert Report the night he was being interviewed and I got the golden ticket!
My wife and I had an enchanting date night for the Christmas party. Utterly gorgeous night. We also had a Mandatory Fun Day at the beach last summer, except for one employee who managed to do major damage to his foot. Apparently sand can be extremely dangerous to walk on.
We've had employees move on. Some went off to join other startups; I feel really good for them when I see updates to their LinkedIn profiles. Some employees got married. It's interesting to watch people grow and change as the company grows and changes. And oh boy has it changed...growing like kudzu, until we needed to move to a new and substantially larger office space, and now even that space is starting to feel a little cramped as the need to double up in offices is looming.
That's pretty much been my professional life for the past year. The post is already long enough to not get into a year of my personal side, the part that gave the blog it's name. Perhaps that will be a topic for another post.
Sunday, August 4, 2013
Responsibility in the Workplace (or, "Hitting a DevOops")
Things go wrong.
That's a universal truth. We can make plans and anticipate problems, but in the end, "Best laid plans of mice and men" will occasionally leave you feeling as if you have little consolation outside the use of salty language and a desire to crawl into the corner of a server room for a few hours.
The important thing to remember is that it's the reaction to things going wrong that will be judged. The fact that something went wrong cannot be be changed; what's done is done.
In terms of the workplace, here are the steps I try to remember:
In the end, the goals are the same.
That's a universal truth. We can make plans and anticipate problems, but in the end, "Best laid plans of mice and men" will occasionally leave you feeling as if you have little consolation outside the use of salty language and a desire to crawl into the corner of a server room for a few hours.
The important thing to remember is that it's the reaction to things going wrong that will be judged. The fact that something went wrong cannot be be changed; what's done is done.
In terms of the workplace, here are the steps I try to remember:
- Take responsibility. Own up to the mistake, if it was your mistake (or your area of responsibility.) Was the task yours to maintain? Were you in charge of managing whatever went south? Maybe you just plain screwed up...you were supposed to order something, and you forgot, for example. Passing it off on someone else or implying it was someone else's fault you didn't follow through just makes you an unreliable douchecanoe.
- Apologize for the mistake. Not in a passive, blame-shifting manner, like those idiots that make a passive aggressive acknowledgement that you're sorry that XYZ feels bad in a crafty attempt to make a non-apology. Apologize in a way that acknowledges your responsibility in the situation.
- Once responsibility is acknowledged, let it go. Responsibility is one thing. Dwelling on it is just wallowing in blame. Blame will not help the situation. You now have a problem to solve. Focus on the problem at hand.
- Rectify the situation. Identify what is wrong, and do what has to be done to make it right. This could be as simple as ordering what was forgotten (expediting the order, if possible) or maybe you'll need to find a workable solution with someone in a team affected by the problem.
- Identify the source of the screw-up. Why did you overlook this? What factors contributed to it? Of course there are times when the problem stemmed from you making a silly mistake. Other times the problem came from a series of failures that maybe you couldn't reasonably foresee. The important thing is to ask yourself if there is a point where this failure could have been reasonably caught and mitigated before it became a problem.
- Revise procedures. Maybe you need to add an item to a procedure checklist. Maybe you need to rely on organized lists. Maybe it's time to overhaul a workflow, or work with others in a team to create a check and balance mechanism.
- Communicate the changes. Tell your manager and others affected by the mistake what will be done in the future so that this mistake will hopefully not be repeated. This shows that you're proactive and taking steps to learn from your mistakes.
In the end, the goals are the same.
- Acknowledge your responsibility and apologize
- Rectify the situation at hand
- Analyze what led up to the mistake being made
- Prevent it from happening again, if possible
- Communicate the changes you're making to prevent future mistakes going forward
Subscribe to:
Posts (Atom)