Posts tagged 'design'
-
One of my understated goals is to transform ideas I've written down from single-sentence entries in a notepad somewhere into something a bit more robust and shareable. While sorting through Bear notes today, I found one idea that I feel I can expand on in short order.
Ticks are fascinating and terrifying creatures. They have one overall motive—to suck blood—and they are singleminded in that pursuit.
In the Army we went into the Kentucky backwoods for a group land navigation course, and during a break for lunch (happily, away from the Drill Sergeants) my battle buddies and I stopped for a tick check. One of our guys—Palmer—found a tick on the back of his arm, in a place that had been covered by his blouse sleeve, and spent the next five minutes freaking out as we attempted to get it off him.
By this late point in our training cycle, our DS allowed us to purchase and carry multitools, and having eaten MREs we had matches on hand. So, remembering the old wisdom about tick removal, we tried heating up a knife blade and putting it on the underside of the tick to get it to release. Between curses and shaking his arm, Palmer informed us that all we had accomplished was burning him. So, we got more aggressive: one of our knives had a pair of tweezers, and we used those to wrench the nasty creature out of his skin. After several attempts, we got the tick out, and (to the best of my knowledge) Palmer was shaken but otherwise okay.
The mere existence of ticks is enough to make me want to have nothing to do with them. If they bit and moved on, like mosquitos, I might tolerate them more. But they bite, and they suck your blood, and they spread diseases like Lyme—which is often misdiagnosed for years, and causes remarkable neurological effects—and can even cause you to become permanently allergic to meat. Seeking to avoid these effects, any time I go into the backwoods or anywhere that has a chance of having ticks, I spent ten minutes with a mirror fastidiously checking every part of my body for ticks. So far, I've been lucky.
However, in their quest for blood, they have pursued me. In 2013, I visited my dad in State College, PA, and together we traveled to Gettysburg to see the battlefield in person. There's a little trail on the east side of the battlefield, a little south of the Union artillery emplacements, that's mostly meant for horses and small vehicles. On a lark, my dad and I began to walk down this trail (consisting mostly of dirt and tall grass) when something—the twitch of a hair, a stir of breeze—prompted me to glance down at my legs.
You have to realize that since Iraq, and the Internet, I'm absolutely paranoid about parasites. So when I saw this little… <expletive> punaise1 crawling among the hairs on my leg, I about lost it. Imagine: here I am, a 230+ lb person, cursing up a storm while trying his damnedest to swat a tick off his legs, while the little bugger is holding on for dear life. It hadn't even bit into me, and already it had a firm grasp.
Now, the internet says that ticks can't jump, but I'm pretty sure I didn't brush any grass while we were walking up that path. Perhaps it got on board the Peter train much earlier, when we were walking out on the battlefield, and I only noticed it once it got higher up and the difference in feeling on my leg hairs clued me into its presence. No matter how it got there, though, I was pretty sure I managed to swat it off, and, not wanting to risk any further encounters, we turned back.
Well, wouldn't you know it, not ten minutes later I found another one (or perhaps the original was more tenacious than I thought). Just as profanely but much more focused, I got rid of this one, and promptly tied my shorts2 as far down my legs as they would go. Crisis averted, we spent a few more hours wandering the battlefield before hopping back in the car to return to the hotel. I spent a chuck of the ride back that night telling my dad (who was apparently uninformed) about the dangers of ticks and Lyme, and encouraging him to check himself.
All this is to say that ticks are very good at what they (try) to do. But there's another, more salient point that I want to bring home. There's a reason health professionals no longer recommend people use the "hot knife" method to remove ticks (other than the risk of burning your battle buddy), and further a reason they recommend you use shard tweezers and grab as far down the tick as possible when removing it.
You see, ticks aren't optimized for letting go; they're optimized for hanging on for dear life. Ticks that let go don't breed. Burning a tick can cause it to vomit into the bloodstream, increasing the risk of catching any diseases they carry, and failing to grab a tick far down its head can cause the head to break off while drinking. The head might not get the message that the body is no longer there, and continue 'drinking' well after it should be dead (again, raising the risk of infection).
Why don't ticks evolve to have a stronger connection between their heads and their bodies? Well, first of all, that's not how evolution works; they have to work in large part with the pieces they have. But, more importantly, a stronger neck is a cost without a direct benefit to the singleminded purpose of hanging on for dear life. A tick with a strong neck might have a better chance of surviving separation from the host, but a tick that risks getting separated from the host at all is a bad tick.
High ROI, from a tick's perspective, comes from a) skill in finding a host b) escaping detection while they seek a good feeding spot c) hanging on while feeding d) escaping to lay eggs. None of these criteria is improved by surviving removal, because when one tick dies, there are many ready to take its place.
If we view design, or business, as a competitive environment like nature, we can see parallels: there isn't much potential ROI from being a "careful" company, to insure against unlikely scenarios. The most successful configurations are those that are singleminded in their pursuit of survival, avoiding the risk of removal in the first place. Your survival chances are dictated not by how "good" a company you are, but rather how dogged you are in pursuing a single goal, and if someone comes along and cuts your company off at the head… that's just business.
-
I have to write for the book I owe in October starting soon, so I've been thinking more about writing in general and how things are communicated. (Perhaps this could be considered semiotic thought?)
The urge to try to tackle a different book has resurged, especially now that I'm writing here without the threat of fine. Writing is comforting; however, this style of writing is a bit too unrefined and "work avoidance" to really lead anywhere. If nothing else, the medium format stuff seems to be a good lead in to starting work, and getting into a good groove. I wonder if other people feel the same way, and that's why some people get to the office early and work on email?
(As a sidenote, perhaps that's reason enough to get out of bed early, other than the cat crying. Maybe I can find something to write about in a longer format and see what happens to my motivation/well-being.)
The segue here is that Tommy asked me for a progress update, and I described to him some of my struggles, and he was pretty good at reassuring me that I'm on the right path. But what helped, and is helping, most, are the short phrases—remember, when you came here, you were already above the top 95%; what's more important than the company is the team you'll be working with, etc.
I try to collect little clippings and reminders of things and hold on to them until they stick with me. This is one of my lingering problems, actually: getting all the clustered information out of my head and into a format where I can manipulate it. I was actually considering exploring some different technologies in order to make a Scrivener knock-off, because the plethora of similar tools never seem to quite mesh up with my needs, but I know that that's probably another blind alley. If I could figure out the interaction model or something, maybe it'd be easier, but it certainly wouldn't be trivial by any means.
It's surprising how much productive work relies around having the right information available in the right format and being able to manipulate it in an easy manner. This is probably the central problem of software, in short: while maybe 90% of apps boil down to CRUD, making interactions painless and contextually meaningful is the where interesting work happens.
There's a link here, though: getting the right "core idea" matters as much in writing as it does in software (or mathematical proofs, or… so many things). In most mental work, there's some foundational piece that helps you stay on track, and helps the audience get in tune with you. Good writing will have a rhythm, where a long description will build to a purpose, or a witty or touching statement, and that will stick with people. Good software has a clear purpose, I think, and should be similarly scrutable to an audience.
-
I've just started to read Corman's Algorithms, and in the first chapter a thought occurred to me.
There was a recent post about how inter-connected the Facebook codebase is. First of all, I found it quite surprising how much code there is, but I assume a good chunk of it is for scalability, which is certainly important (it's basically a mystery to me how facebook works at all, given that there's no way their user database can exist as a single object on a single machine).
However, thinking further, and thinking about the sorts of companies I see out there, it seems like there are a lot of people solving the same kinds of problems. And between one thing and another, I started wondering: how much of this is because our languages for expressing common problems haven't matured?
There's a cap on median engineer intelligence (it doesn't really matter what this means, but for the sake of argument, let's say the median engineer working in web technologies has an IQ no higher than 130, or two sigma above the population). Engineers are in a weird spot inasmuch as they work in one of the few industries where your job is very similar to your training and tool-building. A teacher can take classes on being a better teacher, and make resources to make teaching better and easier, but at the end of the day if they don't get in front of a classroom, they're not doing their job.
An engineer, on the other hand, can write a framework to make their work easier, learn (or create) a domain-specific language to speed up one aspect of their job that's repetitive, and at the end of the day have in hand new knowledge, work that pays the bills, and a tool they can release for other developers to use. This probably goes a long way in explaining the galapagosation of technologies, especially web technologies.
At some point, the learning curve of understanding how everything goes together becomes too challenging. Thus, our median engineer can't get much more efficient, because there are too many things to keep track of, and too many things that can break, and he wants to understand his toolchain and not look a fool because he can't tell his boss why the database got borked.
The thing is, we already have specialists (Database Engineers, SysAdmins, Front-end, Back-end, Project Engineers, the list goes on), and the role of "DevOps" kind of papers over the fact that at some scale, a company should be concerned with differentiation of responsibilities. All engineers should have some idea of how their work might affect other domains, but the job of optimization should lie in the hands of experts. (Note here Conway's Law, which states that "organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations".)
Is it possible to make a framework which would make engineers more productive, and capable of expressing higher-order concepts without having to worry about the entire stack?
One attempt at an answer: the sorts of problems that companies are focused on solving largely center around CRUD, certainly. We're getting to a point where most of the things people want to accomplish involve finding a collection of rows in a database, and presenting them in a way that makes sense to users. Visual pattern matching, just-in-time data delivery, etc, are all very important to making a successful application. But when all the code you use on the front-end is visible to users (via JavaScript) and the actions people take are generally similar across the board (CRUD), creating a niche relies on largely on branding and network effects.
The original "killer app" on Facebook was (probably) checking out the pictures of cute girls in your classes, and bragging about your awesomeness in an attempt to improve social standing, and not much has changed. They leverage more aspects of homo now, ten years on—the desire to be informed, the desire to feel social without the costs—but these things depend on the network that was bootstrapped via "cool, attractive young people".
And yes, I'm being a bit glib, but the problems that Facebook solves in interesting ways mostly center around speed, availability, scale, and presentation. The CRUD core is kind of… boring?
The company that eats Amazon's lunch, by contrast, will make it easier to actually shop, and not just find something close. This is presentation and filtering layer technology, and Amazon's existence hasn't shut the door on other online marketplaces the way Facebook has largely supplanted all other entrants to vanilla social networking.
Amazon's power has come, in turn, from its infrastructure and its internal APIs. Most engineers, when they hear "Amazon" now, will think more naturally of AWS than of the original online bookseller. Sure, Amazon will always mean books on some level, but they drive so. much. of the web that I wouldn't be surprised if that becomes their core business (just like I joke about Google becoming primarily a car manufacturer).
[A funny sidenote: how many online stores, I wonder, are running on AWS on the backend? Amazon is pretty content-agnostic, even when the instances they're hosting would compete with their original niche.]
Meanwhile, technology stacks are maturing—
redisfor cache,capistranofor server management,dockerfor deployment—thus freeing engineers from having to roll their own, so to speak. Interesting companies are getting more meta (sidenote: I really need to play with SquareSpace to see what they enable people to do… but it's possible that they'll kill the indie web dev)… and I don't actually know what the engineers are doing at the rest of these companies? Is it all just gluing frameworks together, whiling away time until the company is aquihired?And there's something empowering to playing the "Full Stack Engineer" game as long as you can. Outside Project Management, FSEs are among the few who can say they're able to realize a vision, which the parts-and-glue, division-of-labor engineers probably can't.
Other than inertia, then, I suspect a primary reason this industry hasn't settled on a single stack is because as long as there's capital flowing, people are having fun at work—and occasionally making money doing so. If software engineers collectively decided they wanted to change the world in a more meaningful way, they certainly could (or at least could make a good stab at it). However, at that point, the majority of the industry would be consigning themselves to grunt work, the sort of work that mostly appeals to milquetoast personalities with pocket protectors, and late-career people with families and hobbies.
A business idea, then, would be "do whatever would make software engineering boring, the fastest, for the most people". That would pull the rug out from under the entire field for a while, though, until the middle-road engineers could figure out a way to build on top of this new stack and have fun doing so.
-
A summary of the majority of the postings I see:
- We want a full-stack engineer
- With skills in our exact tech stack (modulo one or two things)
- With five years experience
I'm not so stupid that I believe everything they say—with work that's important enough and with enough money coming in, they would find a way to make a non-ideal candidate work—but there is no way that there are enough engineers out there able to fit these criteria.
In any industry (or endeavor) there's going to be some "limiting factor". In chemistry, for instance, you generally try to use excess of your cheap reagent to try to get the highest yield possible of your most expensive reagent. However, one has to wonder, where are all the jobs posting asking for engineers with 10+ years experience? (Note: I'm not looking at the "senior" positions, but even if those are looking for people with 10+ years experience, where are the 15 year positions?)
This is the factor that makes me think, especially, that "5 years" is just a shorthand for "we don't want dummies". I doubt there's any industry where dead weight is as dangerous as it is in software; if you can get your foot in the door elsewhere, you can have a career as a mediocre … whatever… but there's not a lot of room for mediocre in software. If you can't understand the standard processes of abstraction, problem solving (etc), there's not much room for you in software.
However, the career progression for engineers is a bit shady. Salaries go from (slave wages of) about $45k to a healthy median of $80-90, up to about $130… and then what? I know one guy who was a project manager and made a very large salary, but I don't hear a lot about a lot of others.
That's an interesting thought, though: is the next level of abstraction above software engineer project manager? The thing that is more abstract than writing large projects is coordinating teams that write large projects, perhaps?
Back to the point, though: no one wants to bear the responsibility for training, and no one wants to bear the risk of getting that one guy who just will never add value to the organization. So I assume, at this point, that the entry point for engineers is a convoluted process of signalling and trials: internships, pedigree, networking, taking chances on people who seem otherwise intelligent.
So far there's nothing novel here. I'm curious, though:
- Is there an overall model that would be able to take advantage of the (presumable) under-tapped pool of future engineers with aptitude?
- Or, is there a model that would pull more people into the industry and train them to produce more?
- Is there a language (paradigm?) that would make programming accessible to more people, or are we already close to peak utilization of programming-capable people in the population at large?
- If so, is there a language (paradigm?) that would take the finite quantity of engineers and make them more powerful?
What's the skill cap on an engineer?
-
One of my hangups about continuing work resolved itself over the past couple days. I ended up having a couple of redundant checkins—"Fixes data model", "Data model finally fixed"—but I think I'm there now.
Collections have models, and certain models, like
Posts, have collections of their own (in this case, comments). When you pull the data from the server for a non-root page, the data needs somewhere to "hang" so as not to face sync problems. So, when I fetch a post, I shouldn't fetch the class it belongs to, I should instead examine the post's section_id property, and then put that in an existing class's post collection. … Got it?User -> Sections Collection -> Section Model -> Posts Collection -> Post Model
So, on fetch of the last item in that chain, I need to go to the head of the chain and request that this data goes in the proper place in that chain.
It took me a while, but I think I ironed out all the kinks. It took moving some logic from the models into the collections: if you ask a
Postwhat section (class) it belongs to, it asks its collection, which in turn had that property set upon initialization. (I also needed to start initializing new collections with(null, options)instead of({}, options)because it turns out{}is a model on its own, just one with no attributes… derp.)What does this mean? A whole bunch of crazy sync problems disappeared all at once, and I can finally see the light at the end of the tunnel. I have never truly had a Minimum Viable Project (MVP), and I'm getting to the point where that feels possible, and likely to happen soon.
-
"Never dine alone." There's a purpose to this: if you're dining, you should seek to share food with someone whose social bonds and career trajectory might benefit you down the road, or with someone you could mentor in some way. In all aspects, you should seek to dine (that is, eat out) with people who can enrich your life, and who can benefit from or provide benefit to you through the social bonds created by the ancient rites of breaking bread together.
Jesus said:
"You are the light of the world. A city set on a hill cannot be hidden; nor does anyone light a lamp and put it under a basket, but on the lampstand, and it gives light to all who are in the house. Let your light shine before men in such a way that they may see your good works, and glorify your Father who is in heaven."
Genius works the same way. Somewhere in the universe is a creature of an alien species that knows the answers to the problem you're working on, but just as his knowledge does you no good in your life, knowledge you don't share with others does them no good in their lives. People work better in messy offices, where ideas can cross-pollinate and you can (hopefully) find someone who speaks a dialect of the language of your problem, and skip out on a lot of the infrastructure that would accompany writing.
In general, a good intellectual peer allows you to do what I've heard referred to as "skip talk": you skip a lot of words and ideas because your companion indicates, using non-verbal and sub-verbal cues that they see where you're going because they've already been there. So you quickly get to the meat of the discussion, and gain a lot of ground there because that person can help you recognize which ideas are worth pursuing.
Once you create something, though, you should polish it to a point that someone who doesn't know you and doesn't necessarily like you can understand it. This is the work that happens alone, for the most part, and that which most resembles "work". The endless polishing, cleaning up of ambiguities, and presentation of data in an understandable format for all to see takes a lot of time, but this is where true genius lives.
-
Today was the .css assessment, and after working late (and falling asleep while working a few times) and doing the practice twice, then studying the solutions last night and this morning, I kicked ass.
To summarize: good design often has a logic, and good instructors are consistent, almost without fail. If there are exceptions, they are for a good reason - your instructor is working at the forefront of the field and the rules aren't established, the design language you're working with has some foibles that you have to work around.
In our case, I've managed to pick up on and benefit from the design habits of our CSS specialist, Jonathan, and have slowly been trying to incorporate them into my own design language. For instance, set consistent (and generous) margins/padding, keep visual space symmetrical, tend to favor making item borders on the inside and container borders on the outside, … and so forth. I haven't built all of this into my site yet—it still looks like baby's first webpage, although thankfully not as 90s as all that—but there are a lot of things coming together very quickly.
Case in point: investing in figuring out backbone means that I've basically added three full collections, three full models, and half a dozen views to my app today alone. I also added two utility … packages? files? to my app that enable some neat stuff, one that makes my life easier, and another that enables a pretty cool "live search" feature to the website.
Yeah, it's all pretty silly overall—I'm reinventing the wheel—but I know why and how I'm reinventing the wheel here, which is okay by me.
There's very little of what I'm doing that is really challenging now, which is okay after the weekend. To use a workout metaphor, this is my plateau, where I'm consolidating gains before looking for more of a training effect. Again, I'm okay with that.
Meanwhile, I'm able to explain to a lot of people what their code is doing wrong, or able to sort through arbitrary code and understand it pretty idiomatically; I'm much more confident with
gitand amaliasing my most common commands regularly, and can find my way around Atom like nothing.Wow, they have taught us something. :P
-
We're all solo all the time from here on out.
Today was super interesting, and super… how to say it… introspective? Revealing? As mentioned, today was the beginning of two weeks of solo work on a single final project, and I spent a lot of time looking at myself, wondering, "what am I doing?"
An aside. We're working on CRUD projects—Create, Read, Update, Destroy—which describes in some way, shape, or form 90% of the web apps that people use. Sure, there are some flourishes, because the "things" in any given web page can be text, videos, votes, cats, whatever, but at the end of the day all that's being done is authentication followed by doing stuff to entries in a database and then serving content.
What makes CRUD apps interesting, then, is the content they provide and the interaction model they offer, as well as the way they integrate the data they have on hand. Stack overflow is a forum with sorting, at the end of the day, but there are layers on layers of customizations and social … stuff they enable that makes them the foremost place for responses to technical questions on the (English-speaking?) web.
Getting to that point is always hard. A lot of the web is still non-RESTful phpBB systems and so forth, whereas what we've been learning is slightly more advanced and much more responsive (not in the screen scaling sense) than the pre-AJAX web.
Today, however, was straight up phpBB-level work. Which made it … weird. It's one thing to be learning Rails for the first time and to know that you're not stopping there, but it's another thing entirely when you have to seriously examine a problem you want to solve knowing that it's just a waypoint on a long path. Needless to say, a lot of the romance has fallen off web technologies for me, now: everything seems pretty easy, in a way (despite my struggles to cover ground today, more on that later), and I'm much less impressed with most single-page apps, or even massive online presences. It all seems like "just" pushing bits around.
Sure, there's a lot to be said for impressive widgets, scaleability, and presentation, but my main bugbears on the modern web all come back to utility. When 90% of the single-page apps feel little more advanced than MS Word's outline view, what are people really doing? I think a new interaction model is due, but I don't know what it looks like. It will, of course, seem obvious in hindsight.
Back to the day, then. I know I was frittering away time, learning about advanced validations or how to be more succinct with Rails. Part of my introspection is realizing that I really do prefer small, focused tasks (bug hunting, making something tiny and super-polished) over architecting… but the model for this project is to cover as much ground as possible, showing off knowledge of many technologies and areas of study as possible. In a sense, breadth, not depth. I bet I could break any of our projects, two weeks from now, in ten minutes if not less—and that's just not the kind of problem solving I like. I'd rather make something tiny and robust than expansive and potentially brittle.
Am I missing the point of MVPs and Agile development?
Tomorrow, my goal will be to subsume my pickiness under the banner of covering ground - I will try to be picky over broader architectural issues. Does that even make sense? They're saying we should be working on Backbone by tomorrow, but I know I'll still be doing a lot of rails for much of the day.
Nonetheless, we pushed to heroku today, and … yeah. It's a bit ridiculous how sparse my app is, but that's life. It'll look better tomorrow, I swear.
-
Today's partner: Marc
Today was the day of the first assessment. It went well—I was less nervous than when I did the practice assessment, which I guess is the point—but I ended up tripping on the same edge cases as I had doing the practice. Derp.
(Technical gore ahead: I was writing a
sortmethod per the instructions, specifically bubble sort—I know, I know—and wrote a helper method to implementbubble_sort!that was called bybubble_sort. Somewhere along the way I started getting wrong argument errors—0 for 1 or 1 for 0, depending on what I was doing at the time—and it took me ten minutes to see that I had been checking the function signatures for errors, when it was the call out to the helper method that was causing the problem.)I felt guilty for finishing early since it seemed like most everyone else was still working, but looking around it seemed a couple people finished earlier than me. Sure enough, looking at tumblrs, another student finished absurdly quickly—the specific student I expected—and really, I ought to have been just a bit slower than him.
A lot of students have that moment when they first enter a highly selective program where they realize they're can't easily be the best anymore. I've had enough time in life to get used to that idea, but really there's little enough excuse for me not to push harder to get better. Having a decent target to reach has helped my typing speed (compared to just typing gibberish in a typing trainer) but I still have to test my assumptions about what a method can handle and what it returns too often for comfort. What I'd like, by the end of this program, is to be in the running as the "best" student and not just coast on … whatever it is that's gotten me this far in life. That will take work, and prioritization.
As any regular reader of this blog will be able to understand, most of my biggest demons are of my own creation.
We spent the entirety of the rest of the day working on Minesweeper. I can tell after a solid week that one of the critical pieces of Pair Programming is how well or poorly the personal dynamic plays out. Historically, I haven't been one who can easily convince another to adopt my priorities. This is another thing that I think raw competence can help with: people will listen to someone who seems to know what they're talking about, especially if they have easy confidence, even if that person doesn't actually know what they're doing (until, of course, that person is revealed as a sham). Further, sometimes the people you have to work with really want to go in one direction when you wholeheartedly believe that another route will bear more fruit. Wrestling with this sort of thing can be exhausting, because either you defend your idea and "win", or you realize the other person has the better idea and concede your point. Either way, you've expended a lot of mental energy.
I'm not saying, mind you, that my partner was particularly difficult to work with. I have had some amazing pairings so far, but today was one of those days where we each had an idea for what needed to happen, and we were pulling in different directions—vectored off from one another just enough that it was a challenge to move forward.
We got where we needed to be by the end of the day. The game worked, we had a somewhat clean data model, and our logic held up. We were even able to add some extensions—we changed the symbols used from rough ASCII to some nice Unicode that I think was much more readable on-screen. But toward 3:00 or so I began to think we ought to order T-shirts that say "Don't worry about that; we'll refactor later." Were this a production codebase, we'd have accumulated a lot technical debt today. Compare this to most of the projects in the first week: my style was much more comfortable and easy to read, with only a couple places (typically method chains) where I could benefit from some cleanup, and I think that's a direct consequence of having a solid idea of where we needed to be and the route we would have to take to get there in the first thirty minutes of class.
That is to say, all of our problems can be traced back to an overall bad approach to architecting the solution, specifically the separation of class responsibilities and the mechanism for passing certain objects. Prototyping, or figuring out a full schema earlier on, may have helped protect us from some wild goose chasing, but as Fred Brooks said, when solving a new problem teams should design a throw-away system first, because you're going to throw the first one out anyway. (See also: Annie Lamott's "Shitty First Drafts")
It's not easy to see your own failings, but looking around some common ones that others demonstrate include a resistance to learning skills that are not core to the "purpose" of a course (the purpose being debatable—I've been at enough colleges to know that what's on the final is a small fraction of what a student needs to learn), stubbornness about one particular approach (kill your darlings!), not being able to listen to others at all, not telling others what you're doing because it's obvious to you, not giving people the benefit of the doubt… to some small extent each of these has manifested in my time here, and I'm on the lookout for those times when I, myself, am guilty of these. Small sins can be hard to see.
It was a good day, overall. I love the people here, but the difference in energy level between a good day an an average day is really noticeable. Still, every day so far has been far better than any day of work or school until this point.