#BI101: Introduction to data warehousing

This is part of a series of articles in which I’m trying to teach myself about BI.  Any related articles I write are preceded with “#BI101” in the title.

Because this is a new (to me) topic, it’s possible that what I write might be inaccurate.  I invite you to correct me in the comments, and I will make it a point to edit this article for accuracy.

As part of my personal education about business intelligence, I kicked off a SkillSoft course made available to me through my employer.  My strategy is to take the course, perform some supportive research, and write about what I learn.  It turned out that BI was one of the training options available.  So, I kicked off the course and began my training.

The initial topic discussed the concept of data warehousing.  The course began with a pre-test — a proverbial “how much do I really know?”  There were a few subtopics that were familiar to me — normalization and denormalization, for one — so my initial thought was, how much do I have to learn?  As it turned out, the answer was, a lot.

What is a data warehouse, and what does it do?

The short and simple answer is that a data warehouse is, as the name implies, a storage repository for data.

That’s the short answer.  The longer answer gets a little more complicated.

Data warehouse architecture (source: Wikipedia)

I learned that a lot of the concepts behind a data warehouse pretty much breaks a lot of what I thought I knew about relational databases.  For starters, I’ve always been under the impression that all relational databases needed to be normalized.  However, I learned that, in the case of a data warehouse, that might not necessarily be the case.  While a data warehouse could be normalized, it might not necessarily be.  While a normalized database is designed to minimize data redundancy, a denormalized data table might have redundant data.  Although it occupies more space, having redundant data reduces the number of table joins, thus reducing query time (as the SkillSoft lesson put it, sacrificing storage space for speed).  When a data warehouse is storing millions of rows of data, reducing the number of query joins could be significant.

Populating a data warehouse

How does data get into a data warehouse?  It turns out that a data warehouse can have multiple data sources — SQL Server, Oracle, Access, Excel, flat files, and so on.  The trick is, how does this data get into a data warehouse?  This is where the integration layer comes in.

Because the SkillSoft course I took was SQL Server-specific, it focused on SSIS.  SSIS provides tools that allow it to connect to multiple data sources, as well as tools for ETL (Extract, Transform, Load).  ETL involves a process that includes obtaining data from the various sources and processing it for data warehouse storage.  A big part of ETL is data cleansing — formatting data so it is usable and consistent.  For example, imagine that several data sources use different formats for the same Boolean data field.  One uses “1” and “0”, another uses “T” and “F”, another uses “Yes” and “No”, and so on.  Data cleansing formats these fields into a single, consistent format so that it is usable by the data warehouse.  As there are many such fields, ETL is often a very long and involved process.

Just the facts, ma’am…

I had heard of fact and dimension tables before, but I wasn’t entirely sure about their application until I started diving into BI.  In a nutshell, facts are raw data, while dimensions provide context to the facts.

To illustrate facts and dimensions, let me go back to one of my favorite subjects: baseball.  How about Derek Jeter’s hitting statistics?  Clicking “Game Log” displays a list of game-by-game statistics for a given season (the link provided defaults to the 2014 season, Jeter’s last season).  Looking at his last home game on Sept. 25, Jeter accumulated two hits, including a double, driving in three runs, scoring once, and striking out once in five at-bats.  These single-game numbers are the facts.  The facts are these raw numbers that Jeter generated in that single game.  A fact table stores these individual game statistics in a single table.  Dimensions provide context to these numbers.  Some dimensions might include total accumulated statistics for a season, batting average, and some (non-statistical) information about Jeter himself (name, hometown, birth date, etc.).  These derived statistics would be stored in dimension tables.

If you’re still confused about fact and dimension tables, I found this question on StackOverflow that does a pretty good job of answering the question.  I also came across this article that also does a good job of describing fact and dimension tables.

Stars and snowflakes

Star schema (source: Wikipedia)

A fact table usually maintains a relationship with a number of dimension tables.  The fact table connects to the dimension tables through a foreign key relationship.  The visual table design usually resembles a star, in which the fact table is at the center and the dimension tables branch out from the center.  For this reason, this structure is called a star schema.

A snowflake schema is related to the star schema.  The main difference is that the dimension tables are further normalized.  The resulting foreign key relationships result in a schema that visually resembles a snowflake.

Snowflake schema (source: Wikipedia)

Attention, data-mart shoppers…

A data mart can probably be considered either a smaller version of a data warehouse, or a subset of a data warehouse (a “dependent” data mart, according to Wikipedia).  As I understand it, a data warehouse stores data for an entire corporation, organization, or enterprise, whereas a data mart stores data for a specific business unit, division, or department.  Each business unit utilizes data marts for various information purposes, such as reporting, forecasting, and data mining.  (I’ll likely talk about these functions in a separate article; for our purposes, they go outside the scope of this article.)

So, this winds up what I’ve learned about data warehousing (so far).  Hopefully, you’ll have learned as much reading this article as I have writing it.  And hopefully, you’ll keep reading along as I continue my own education into BI.  Enjoy the ride.

 

#BI101: An introduction to BI using baseball

Edit: This is the first of a series of articles (I hope!) in which I’m trying to teach myself about BI.  Any articles I write that are related to this, starting with this one, will be preceded with “#BI101” in the title.

As I stated in a previous article, one topic about which I’m interested in learning more is business intelligence (BI).  For those of you who are new to BI, it is a broad topic.  In a nutshell, it can probably be described as “consuming and interpreting data so it can be used for business decisions and/or applications.”

I’ll admit that I don’t know a lot about BI (at least the fine details, anyway).  I did work a previous job where I touched upon it; I was tasked with performing some data analysis, and I was introduced to concepts such as OLAP cubes and pivot tables.  I’ve gotten better at creating pivot tables — I’ve done a few of them using MS Excel — but I’ll admit that I’m still not completely comfortable with building cubes.  I suppose that’ll come as I delve further into this.

A while back, my friend, Paresh Motiwala, suggested that I submit a presentation for Boston SQL Saturday BI edition.  At the time, I said to him, “the only thing I know about BI is how to spell it!”  He said to me (something like), “hey, you know how to spell SQL, don’t you?”  Looking back at the link, I might have been able to submit (I didn’t realize, at the time, that they were running a professional development track).  That said, Paresh did indeed had a point.  As I often tell people, I am not necessarily a SQL expert — I know enough SQL to be dangerous — nevertheless, that does not stop me from applying to speak at SQL Saturday.  Likewise, as I dive further into this topic, I’m finding that I probably know more about BI than I’ve led myself to believe.  Still, there is always room for improvement.

To tackle this endeavor, once again, I decided to jump into this using a subject that I enjoy profusely: baseball.  Baseball is my favorite sport, and it is a great source of data for stat-heads, mathematicians, and data geeks.  I’ve always been of the opinion that if I’m going to learn something new, I should make it fun!

Besides, the use of statistical analysis in baseball has exploded.  Baseball analytics is a big deal, ever since Bill James introduced sabermetrics (there is some debate as to whether James has enhanced or ruined baseball).  So what better way to introduce myself to BI concepts?

For starters, I came across some articles (listed below, for my own reference as much as anything else):

I also posted a related question in the SSC forums.  We’ll see what kind of responses (if any) I get to my query.

Let’s start with the basics — what is BI?

Since I’m using baseball to drive this concept, let’s use a baseball example to illustrate this.

Let’s say you’re (NY Yankees manager) Aaron Boone.  You’re down by a run with two outs in the bottom of the 9th.  You have Brett Gardner on first, Aaron Judge at bat, and you’re facing Craig Kimbrel on the mound.

What do you do?  How does BI come into play here?

Let’s talk a little about what BI is.  You have all these statistics available — Judge’s batting average, Kimbrel’s earned run average, Gardner’s stolen base percentage, and so on.  In years BS — “before sabermetrics” — a manager likely would have “gone with his gut,” decided that Judge is your best bet to hit the game-winning home run, and let him swing away.  But is this the best decision to make?

Let’s put this another way.  You have a plethora of data available at your fingertips.  BI represents the ability to analyze all this data and provide information that allows you to make a good decision.

If Aaron Boone (theoretically) had this data available at his fingertips (to my knowledge, Major League Baseball bans the use of electronic devices in the dugout during games), he could use the data to consider Kimbrel’s pitching tendencies, Judge’s career numbers against Kimbrel, and so on.  BI enables Boone to make the best possible decision based upon the information he has at hand.

I do want to make one important distinction.  In the above paragraphs, I used the words data and information.  These two words are not interchangeable.  Data refers to the raw numbers that are generated by the players.  Information refers to the interpretation of that data.  Therein lies the heart of what BI is — it is the process of generating information based upon data.

What’s there to know about BI?

I’ve already mentioned some buzzwords, including OLAP, cubes, and pivot tables.  That’s just scratching the surface.  There’s also KPIs, reporting services, decision support systems, data mining, data warehousing, and a number of others that I haven’t thought of at this point (if you have any suggestions, please feel free to add them in the comments section below).  Other than including the Wikipedia definition links, I won’t delve too deeply into them now, especially when I’m trying to learn about these myself.

So why bother learning about BI?

I have my reasons for learning more about BI.  Among other things…

  • It is a way to keep myself technically relevant.  I’ve written before about how difficult it is to stay up-to-date with technology.  (For further reading regarding this, I highly recommend Eugene Meidinger’s article about keeping up with technology; he also has a related SQL Saturday presentation that I also highly recommend.)  I feel that BI is a subject I’m able to grasp, learn about, and contribute.  By learning about BI, I can continue making myself technically valuable, even as my other technical skills become increasingly obsolete.  Speaking of which…
  • It’s another adjustment.  Again, I’ve written before about making adjustments to keep myself professionally relevant.  If there’s one thing I’ve learned, it’s that if you want to survive professionally, you need to learn to adjust to your environment.
  • It is a subject that interests me.  I’m sure that many of you, as kids, had “imaginary friends.”  (I’ll bet some adults have, too — just look at Lieutenant Kije and Captain Tuttle.)  When I was a kid, I actually had an imaginary baseball team.  I went as far as to create an entire roster full of fictitious ballplayers, even coming up with full batting and pitching statistics for them.  My star player was a power-hitting second baseman who had won MVP awards in both the National and American leagues, winning several batting titles (including a Triple Crown) and leading my imaginary team to three World Series championships.  I figured, if my interest in statistics went that far back, there must be something behind it.  Granted, now that I’ve grown up older, I’m not as passionate about baseball statistics as I was as a kid, but some level of interest still remains, nevertheless.
  • It is a baseline for learning new things.  I’ve seen an increasing number of SQL Saturday presentations related to BI, such as PowerBI, reporting services, and R.  I’m recognizing that these potentially have value for my workplace.  But before I learn more about them, I also need to understand the fundamental baseline that they support.  I feel that I need to learn the “language” of BI before I can learn about the tools that support it.

So, hopefully, this article makes a good introduction (for both you and myself) for talking about BI.  I’ll try to write more as I learn new things.  We’ll see where this journey goes, and I hope you enjoy coming along for the ride.

Better Comments

This is a reblog of a post by my friend, Steve Jones. I’ve often said that commenting code is a form of documentation, and needs to be done more.

Voice of the DBA

I assume most of your comment your code.

Well, you probably comment code most of the time.

I’d bet your comments have quite a bit of detail.

And you do this completely inconsistently.

That’s what I’d think, or maybe just what I want. Even the best developers I know will not consistently comment code. You can drift through any project on Github and see this. Those projects on GitHub might even be better documented because people know they are public. In most corporate environments I have worked in, I’ll find that when people get busy, or distracted, or even when they’re experimenting to find a solution, and they don’t write detailed comments. Usually only when someone fixes a bug, with a solution found quickly, do I get a really useful comment.

There are all sorts of ways that people think about commenting their code. I ran across a post from…

View original post 254 more words

Keeping up with technology — revisited (again!)

A while back, I referred to Eugene Meidinger‘s SQL Saturday presentation about keeping up with technology.  I came across his ‘blog article where he talks about exactly that.  It’s a very good read, and he gives an excellent presentation.

Eugene will be giving this presentation in Rochester on March 24, which happens to be the same SQL Saturday where I’ll be speaking! </plug>

Hope to see people there!

Document maintenance is critical

I had two appointments this past week.  The first was one for my car to get my oil change and to make sure everything was in good working order (it was).  A couple of days later, I had a dentist appointment.  It was a routine cleaning (I also had a procedure done — one that I’d been putting off for a while).  While the two appointments were for different reasons, they both served the same purpose: to perform maintenance.

Just about everything, especially anything mechanical, is going to break down over time.  Maintenance ensures that things remain in good working order.  But when we think about maintenance, we usually think about car repair, roadwork, furnaces, and water heaters.

I’m sure many people in tech industries consider periodic hardware and software maintenance.  Hardware can break down.  Drives crash occasionally.  CPUs are upgraded to keep pace with emerging technology and to support software.  Speaking of software, bug fixes are constantly made.  There’s also the matter of security; virus software definitions are constantly updated, and operating system patches are distributed to ensure computers are safe.

But here’s another question: when was the last time you maintained your documentation?  Does your documentation, which was written for, say, Version 1.0, reflect what is in Version 2.0?

The trouble with documentation, even the best-written documentation, is that it can become obsolete over time.  Processes and systems change.  Interfaces are redesigned.  Steps become more efficient, or in some cases, even eliminated.  Change happens.  It’s one of the sure things in life.  Documentation should also change as well.  How often has your help desk received calls from frustrated customers saying things like, “your instructions say ‘press the red button,’ but there’s no red button on the interface!”

If your product changes — and it inevitably will — your instructions should change with it.  It’s important that systems are maintained.  Your documentation should be maintained as well.

My first podcast interview!

About a week ago, I received an email from Carlos Chacon of SQL Data Partners inviting me to take part in a podcast.  This was my first such request, and I jumped on the opportunity.

The podcast recording took place last night.  My topic was along the lines of “writing and communication: why it matters to data professionals.”  It was a lot of fun, and I very much enjoyed talking to Carlos and his partner, Steve.

The podcast should air sometime in March.  It will be posted on their ‘blog.  When it does, I’ll make sure that I post a link to it!

Upcoming SQL Saturday dates for me

Looks like my SQL Saturday schedule will be busy!  Here are my upcoming dates (and I admit that I’m writing this for my own reference as much as anything else).

Scheduled to speak

I am scheduled to speak at the following event:

Presentation abstracts submitted

I submitted my presentations to these events; no guarantee that I will be picked to speak at any of these, but you never know:

Save the date

Event that is on the calendar, but not yet scheduled (hence, there’s no link to it yet); I intend to submit to it when it goes live:

  • July 28, 2018: Albany, NY (my hometown SQL Saturday!)

SQL Saturday is a great, free conference for anyone who wants to learn more about SQL Server.  Many interesting topics are presented, it’s a great opportunity to network, and it’s a lot of fun!

Hope to see people there!

Musings from a frustrated technical writer

(Source: dilbert.com)

As someone who has professional technical writing experience, I am often asked to edit or rewrite documents written by other technical professionals such as developers, IT personnel, managers, and so on.  The ability to create good functional instructional documents is a skill — just like the ability to write good object-oriented and structured code, to design good database table structures, or to properly articulate a difficult run in a piece of music.

Unfortunately, too many people don’t understand that, which is baffling to me.  I’ve seen instances where technicians threw together their poorly organized (and I use that word loosely), badly written notes into a Word document and sent it to a customer, saying “here’s the documentation.”  More often than not, technical writers are disrespected, looked down upon, and are often the first ones cut when budget cuts come into play.  Too many organization and departments say, “documentation is not a priority.”

The problem is, documentation is and must be a priority.

Not everyone can write.  I understand that.  By no means do I intend this article to make technical writers out of people; after all, people do this for a living, and a good chunk of my master’s degree revolves around its principles.  If an entire degree program focuses on documentation and communication principles, there is no way I can cover it all in a single article.  Rather, I’m looking to raise awareness of the documentation skill set and how people can improve the process.  My hope is that this article makes life easier for all professionals.

So with that, here are some tips that I’ve established, through many years and projects of painful experience.

Technical documents come in all different flavors, shapes, and sizes.  I’ve often asked people the first thing that comes to their mind when I say “technical writing.”  I’d guess that, about 95% of the time, they answer either “step-by-step instructions,” “manuals,” or something similar.  I’ll often respond: “what about flowcharts, online help, diagrams, org charts, admin guides, user guides, web sites, UX/UI guidelines, ‘blogs, application menus, and so on” (and maybe even a few other things I haven’t thought of).

Know your audience: This may very well be Rule #1 when writing documentation.  Above all, you need to know who will be reading your document.

People will have different levels of expertise.  They might know some terms, but not know others.  The trick is being able to talk to them at their level, while at the same time, not insulting their intelligence.

Don’t tell me how to build the clock!  Just tell me what time it is!  I once worked for a CTO who was very fond of that quote, but it makes a lot of sense.  Far too often, inexperienced “writers” feel like they need to explain every single tidbit of detail when they’re trying to convey an idea.  Not only is this unnecessary, it’s counterproductive.  Bogging information down with too much detail where it’s not needed makes a document nearly impossible to follow.  A good technical document must be able to describe a task in as few words as possible.  This is not an easy task (and I’m amazed — and not in a good way — as to how many people think this is not a big deal).  Generally, my rule of thumb is, if an instruction cannot be understood or followed quickly and easily (generally within a few seconds, but primarily within a minute), the document has failed.

Having said that, there are times when some documents need to have every detail spelled out (a systems administration guide or reference — which isn’t necessarily meant to be followed quickly — comes to mind).  There are exceptions to every rule.

Never, EVER, assume that just because you know a term that your audience will.  Much of this goes back to knowing your audience.  Often, you need to make assumptions about people who will be reading your document.  But will those assumptions ever be 100% accurate?  I’ll bet my house that the answer is no.  Say, for example, you’re working with a teenaged college intern.  Will he or she understand acronyms and terms such as SQL, Artifactory, ETL, XML, BI, content management, UX, PaaS, and so on?  That person may know some of the terms, but not necessarily all of them.  Even I’ve come across many examples where I didn’t understand a document’s context simply because I didn’t understand the terminology.

Never assume that anything is “obvious.”  I created a generic checklist template that included a set of instructions as to how to best utilize it, and I asked my teammates to take a look at it and give me any feedback on it.  One comment I got was, “some of the instructions should be obvious.  You shouldn’t need to spell it out.”

My response: you’d be surprised.  Even I’ve scoffed at the warning on the coffee cup that said “the contents of this cup are hot” or the message on the laundry detergent that said “the gel pack should never be eaten.”  However, I’ve seen too many instances where some task was “obvious,” yet the end user found a way to use it incorrectly — often in ways that never occurred to me.  Almost anything can be misconstrued, misunderstood, or misused.  Something you think might be “obvious” might not be.

Your document needs to make sense.  Writing a step-by-step document is like writing a program.  It must follow a logical order.  Before you tell someone to walk through a door, you must first tell them to open the door.  (Yes, I realize this is a painful example of my earlier point of “don’t assume anything is obvious,” but I digress.)

You are providing guidance, NOT holding a conversation!  One of my big pet peeves in an instructional document is the use of “conversational” or “social” language.  For example: “Please look at these instructions,” “it is okay to perform this step,” “you should be able to run this,” and so on.  An instructional document is not a social network.  You are not holding a conversation or politely asking someone for a favor; you are telling them how to perform a task.  People read instructions in order to perform a task, and they are looking to your document, assuming that the author has some measure of expertise, for guidance.

On the flip side, you also don’t want to be too forceful with your language, unless the task is potentially catastrophic.

How formal should a document be?  It depends on the document.  For example, does a document require a cover page or an introduction?  Consider the following:

  • Who is your audience?
  • What kind of instructions are you writing?
  • How concise does it need to be?

The more questions your document can answer, the better.

Good grammar helps.  I am a self-admitted grammar-nazi (if you’ll excuse that politically-incorrect word).  I understand the difference between “your” and “you’re.”  I cringe every time people end plural nouns with an apostrophe-S.  And I believe that anyone who uses the word “irregardless” should be sentenced to a lifetime of hard labor.

Having said that, I understand that not everyone is a good writer.  I should also mention that English is my first language, so I’m not as well-versed regarding grammar in other languages (other than maybe German, as I struggle to remember my German classes from back in high school).  (My Korean mother is also fond of telling me about how Korean is grammatically perfect — all the rules are followed; there is no “I before E” or anything like that, but I digress.)

So why mention grammar at all?  A well-written document should be relatively easy to read.  For example, one of my presentations promotes using active, as opposed to passive, voice.  Often, I’ll ask my audience why they think that is the case.  I’ll often answer that question with another question: which sentence is easier to read?  Good grammar goes a long way in addressing that.

While we’re on the subject of easier to read…

Reading is work!*  People often fail to realize this when they write.  Technical documents, especially instructions, are meant to be followed quickly.  My usual rule-of-thumb about a set of instructions is, if it can’t be understood within a few seconds, it has failed.  But people keep insisting on including every single detail in an instruction (see my comment above about “not telling me how to build the clock”).  If a person has to put effort into understanding what you’re writing, it defeats the purpose of why you’re writing in the first place.

If you think bad writing isn’t a big deal, consider these examples (under “Poor Writing and Liability”).

(*Speaking of “reading is work,” this article is becoming longer than I expected.  If you’ve read this far, I’m impressed!)

If you’re using examples, make sure they are relevant to what you’re talking about.  I recently edited a document in which the writer talked about a configuration setting.  He included a code snippet that illustrated the configuration, which was good.  But he also included a snippet that showed how the application logged into the environment — which was not good.  What does login code have to do with the configuration?  Extraneous examples and illustrations only confuse the reader, not make it clearer.

And speaking of illustrations…

A picture is worth a thousand words…  but there IS a wrong way to use them!  I learned very early that an illustration, if done properly, can explain a task better than words ever can.  The document in question involved inserting an optical data platter into a WORM (Write Once Read Many)** device.  The platter had to be inserted in a certain way and a certain side up.  As part of the document, I drew an illustration of how the platter should be inserted.  The drawing saved me the trouble of writing descriptive text that would have likely confuse the reader.

(**This is what I mean by not assuming readers know terminology.  See what I did there?)

However, I also saw an example where an instruction in an Excel spreadsheet told the reader to “look at Figure A.”  First, the reader had to click a link to see “Figure A” (it was on a separate tab, and nowhere near the text, which forced the reader to go back and forth, which was extremely distracting).  Second, “Figure A” included a icon snippet with a part of it circled.  That was it!  There was no explanation about what it was, and because it was only a snippet, there was absolutely no point of reference as to its significance.  (Think about a Google map zoomed in to the point where all you see is the pin and a street, with no idea as to the location, city, state, or even country.)  This was a useless illustration.  It’s said that a picture is worth a thousand words, but if they’re not used properly, their worth in words can be zero.

Your document is a reflection of your organization.  I think this is especially true if documents are sent to clients or even the general public.  Let’s say you’re a customer who gets a hold of a company’s badly-written document.  What would you think of that organization?  Chances are, you’d probably have a low opinion of the company.  Would you want to do business with an organization that produces poor-quality documentation?  My guess is, probably not.


These are just some of the frustrations that I (and other writers, I’m sure) have experienced.  I could probably continue, but at this point, this article likely violates several of the tenets that I’ve espoused above.  In any case, it’s my belief that bad (or no) documentation is a recipe for disaster.  Raising awareness of document criticality can go a long way in making for a better organization.

Time is Precious

My friend, Steve Jones, wrote this article, and it is well worth the read (most of his articles are), even if you’re not a technology professional. If you care about your craft — no matter what it is — set aside a little bit of time to improve upon it.

Voice of the DBA

I’ll hear people constantly say they don’t have time to work on their career. They can’t attend a UG meeting to network. They can’t spare a minute to go through a Stairway Series. They have family commitments, kids, hobbies, volunteer activities, spiritual needs, and more. That’s not even counting all the work they need to get done as a part of their job. When can they spend time on R or Machine Learning or CosmosDB or anything else?

I get it. My life is chaotic as well, with deadlines and a pile of work that never goes away. I sometimes dread travel and vacation because that means my work piles up on either side of those events. This is on top of commitments to keep up on chores at home (I have cooking and laundry), fix things at the ranch, spend time with kids, get date nights with my…

View original post 440 more words

Looking Back

This is a reblog of a post from my friend, Steve Jones. He touches on a topic that is near and dear to my heart, and one that I strongly believe is crucially important.

Nearly all of my SQL Saturday presentations have revolved around documentation and technical communication. Technology may have changed over the years, but the importance of documentation has not. I strongly believe that documentation is getting to the point where it is being dangerously ignored, something that we, as technical professionals, cannot afford to do.

Voice of the DBA

Someone sent me this post on 40 years of programming. It’s a read that laments a few things and complains about many others. Most of the thoughts are opinions, and as such, you may or may not see validity in them. I suspect most of you, like me, see some things are mostly true and some as just false. Since I’ve been in this business for nearly 30 years, many of the comments bring back memories and thoughts about my career as well.

One of the things I do lament is the declining quality of documentation. I’ve seen the volume and detail decline over the years. I wouldn’t want to go back to paper, but I would like to see better examples and more complete examination of the ins and outs of the various functions and features. Far too often I find that there are examples, explanations, or behaviors…

View original post 398 more words