Tuesday, May 17, 2016

Eventually Crappy People Show Up, and I'm Flattered

ShopToTrot has been out for a little more than a year now. We've gotten enough users for me to say that there is enough interest to keep going, and that feels really really killer. Like anything that attracts people online, some people that come through can be, well Crappy. There, I said it. By Crappy I mean that they have no intention of using the system as it was intended. They are there just to cause trouble.


Well ShopToTrot has received enough attention that we've gotten our first Crappy user that hung out just to put junk ads into the system. This one did have a sense of humor though. He or She at least mocked us a bit by putting in a photo of their "horse" (seen above) that mirrored our stock photo that we use if you don't put any pictures of your horse in (seen below).


For a moment, I was highly irritated. But that shortly gave way to flattery. Someone cared enough to come into our system and stink it up a bit. My point to all of this is simply, enjoy the Crappy people. They can't help themselves, and truly probably need a hug.

More to the point, they are a signal that you are becoming successful. And... if it weren't for them, you might not harden the system.

Wednesday, April 27, 2016

My Manager Hat vs. My Worker Hat

I mentioned a while back that one of the podcasts that I've been listening to is Simple Programmer, by John Sonmez. He gave some advice to a listener, and I've had it rolling around in my head since I heard it from Episode 120: Do I Have To Be An Entrepreneur To Be Successful. Just recently I've started to walk in that piece of advice.

I may get some of the particulars incorrect, but the overall gist will be in the spirit of the exchange.

John told the guy that to make progress in his extra goals, he needed to have the ability to wear two hats.  As I remember them, they were:
  1. A Manager Hat 
  2. A Worker Hat (I lovingly call this one the Doer or Executor Hat so if you see me use those alternate forms you’ll know to what personality I’m referring to). 




The Manager Hat:

This is the hat that you wear when you're deciding what should be accomplished by your Worker. So effectively, what he was saying is that you need to take some time to plan out your week. Be deliberate about setting goals for what would get accomplished during that week so you can keep sight of them. I've chosen Sunday night at 9:30 for this hat to adorn my head.




The Worker Hat:

The other hat he mentioned you needed to pick up is a Worker Hat (or a Doer Hat). This is the hat you put on once the Manager Hat comes off. You wear this hat for the rest of the week. Once this hat comes on you simply execute the plan unquestioningly. You don’t deviate from it, you just simply do what your Manager has planned for your Doer.

Once you get through the week, wash, rinse, and repeat for the following week.



In Practice (as I have experienced it thus far):

As I have tried to operate in this, I’ve discovered that my Manager always has unrealistic expectations of what my Worker can accomplish. Big surprise right? That’s often the case in the real world, outside of this little dual personality experiment that I’m doing. So what does that really mean you may ask. Well, for me it’s meant that what my Manager has scheduled for a particular day might not be what my Worker has been able to accomplish for that day. And there isn’t anything scheduled for this thing that my Worker hasn’t finished on the next day coming up.

Sooooo, my Worker had to negotiate with my Manager. The Worker had to tell the Manager, “Hey dude, I’m not done. I haven’t been slacking, it’s just that it’s taking me longer… or life has happened and inserted itself in the middle of your pre-scheduled routine, thus disrupting the schedule."  If you’re anything like me, you’re trying to accomplish these things in the midst of working at your day job, raising a family, and potentially working on these things with other people. Any one of those three things tend to try and get in the middle of your Worker accomplishing what your Manager has laid out. It happens, we’re human, and plans may need to change.

So how have my Manager and Worker adjusted expectations of what will get accomplished. Well, the Worker starts out the week working diligently on those things scheduled by the Manager. And if the Worker isn’t able to complete a day's tasks, then the unfinished task/s get pushed to the next day by the Worker, and the things that were scheduled for the next day get pushed accordingly through the week. The Manager has placed a bucket at the end of the week to catch anything that gets pushed completely out of the week, and things are pulled from that bucket for scheduling the next week.

This way, the Worker has some sense of continuity and doesn’t get disgruntled with not having completed anything at the end of the week, but has spent it thrashing about trying to accomplish everything (when that might not be possible). It’s important for progress and the Worker’s feelings and sense of accomplishment to complete things and get them behind him. If the schedule needs to be adjusted then so be it, the Manager needs to compromise.

This has made the things that I've been trying to accomplish more concrete. And by "more concrete" I mean that there are very real time slots for work to slip into, and expectations on myself that those things scheduled (and only those things scheduled) should be completed.

Life is going to happen. Your plans will get disrupted. You need to be able to adjust, and in the adjustment not loose focus on what your goals are.




In the closing, figuring out the balance between your Manager Hat and your Worker Hat can be Detective work for a while. But in the end you can find some happy medium and hopefully some cadence as to how much you’ll be able to accomplish in your upcoming week.

Monday, February 29, 2016

Lunchtime at The Movies

Well, not exactly at the movies (although that would be nice). I've started doing something at work to try and socialize and spark discussion on either technical things or the process of building software types of things. It's a divergence from the occasional post stand-up video showing off some insane accomplishment someone does in a car, or on a motorcycle, or skateboard, or bicycle. It's a bit more serious than that, and for good reason.




One of the great things about working with a team of good people (and by good I mean you care about producing useful stuff and helping out your fellow humanzies) is that everyone has been exposed to different things, have differing bases [bey-seez] of knowledge, and hold their own ideas about technology and the world. You may find out about them either through pairing with folks, coming together as a larger team to solve a problem, over coffee, or on a team outing.

Another avenue is over lunch while watching a video. We live in a time where content is being put out at an unheard of pace. Conferences will often put out either some or all of their material after the conference for absolutely free (truly a service to fellow humanzies at large, looking at you StrangeLoop... thank you). This gives us commoners a chance to gain access to well thought out technical discussions about all kinds of things that we normally would never have access to unless we work for employers that find value in sending us to some conferences (and most employers unfortunately do not do so), or we take the initiative and foot the load ourselves.

Having an area to watch things like this is extremely helpful, and I don't mean everyone crowding into one of your fellow colleagues cubicles and squinting to watch it on their tiny laptop monitor. I mean a proper spot with a nice large screen and comfortable seating to relax, eat lunch, enjoy one another's company, and learn.

Lunchtime at the movies, for me, aids in spreading some of the thoughts and things that I may be interested in out to my larger team. I've pulled together some of the places that I look to for snagging a video from below. If you tend to watch vids of stuff from the chatterboxes in our industry, where do you cull them from? I'm not looking for Pluralsight or Udemy types of courses, but more conference or meetup/usergroup types of things.

Sunday, February 21, 2016

What are your favorite podcasts?

Being a husband to my wonderful wife, father of 2 amazing kids, employee of an awesome company, creator of things (like ShopToTrot), someone who is trying to blog more, create more, do more, yada... yada... yada, time can be scarce. One of the tools that I use to keep in touch with what's what in technology land is podcasts.


I usually sneak in a listen on my way into work after I've dropped off my little munchkins at school, which typically amounts to 15 to 20 minutes of geekery. While I typically don't make it through an entire podcast in one sitting, as most run about an hour, I get enough of a fix on my morning drive to keep tuning in the next day. It's just enough to give me something to think about either actively or on one of my many background threads that like to solve things subconsciously for me.

Is there always a direct benefit to my daily grind... no. But it does keep me abreast of techno land in a way that nothing else can. I don't always have time to sit down and read deeply about a subject, and this helps to gain a deeper than surface level understanding on some topics.

Here's what I've been listening to lately:

SE-Radio - This is one that I hit for what I call bigger fish I guess. It's where I'm more likely to run across someone like Linda Rising, someone chatting about CAP theorem, or a good hearted discussion about the GOF 20 years after the initial publication of their book.

The Changelog - This is where I go to get my open source fix and things that might be more on "the edge".

Simple Programmer - This is where I hit for good advice on moving my career forward and personal development (and in all honesty I relate to the guy).

I did a search for "github podcast" and this awesome list turned up from Guilherme Dutra (thanks dude, it's a part of the awesome list of lists). It contains quite a bit and perhaps you can discover something new there.

I've recently started using Overcast to manage and listen to my podcasts, I recommend it. One of the reasons I made the hop was I wanted something that helped in controlling what podcasts actually got pulled down to my phone vs. allow me to stream. Overcast will let you set how long to hold onto a podcast before deleting it... you can always go back and grab it again if you need it. If you decide to use it, be kind and drop the folks that make it a few bucks... nothing in life is free.

This isn't necessarily my complete list or my historical list, but it is the list that's comprised my last 6 months or so. I'm interested to know, if you listen to podcasts, regardless of if they are technology related or not, what are they? Everything I listen to isn't necessarily technology related (although lately they have been), and I would love to know what your tuning in to and why you are tuning in.

Sunday, February 14, 2016

One Class Per File

I've been using C# as one of my primary languages for the past 6 years where I currently work. Prior to that I was working with Java. One of the immediate differences that I noticed was that it was not uncommon to have multiple public classes in a source file. C# allows it, so why not.

Coming from a Java background I was used to one public class per file, where the filename needed to match the public classname in the file, and for me... I preferred it that way. I felt that it helped to organize the code. Some may say, having multiple classes in a file can aid in readability/discoverability/understandability/insert-an-ability. All true, they can. It can also be harmful in each of those respects as well... all depends. 

This week I've discovered a new reason why I prefer one class per file. Changes to classes are more traceable if a class has it's own file. Huhhh?




The reasoning goes like this. If I start out and have a couple of small public classes in a file, then tracking changes doesn't seem too difficult. The problem comes in when the classes grow. Your file will becomes larger and larger, and when you look at the file, there might all of a sudden be too many concepts in the file for you to keep track of. This can especially be the case where you can have a file named a name that has nothing to do with any of the classes inside of it (poor form imo, but to each his own). Some of the classes in the file may be related to the filename, but if sloppiness has crept in (not unheard of) then other classes may not be as closely related to that filename. Different concepts and abstractions may have crept into the file, and you may not realize it for a while. Yuck.

Then one day your in the file and your like, ZOMG, this file is too large and has too many concepts in it, I have to tease it apart. And so you do. You become the boy scout and you tease classes out of it, putting them in their respective files with the respective filenames and namespaces. And when you do this, your original file can in the worst case be empty (remember, the filename doesn't have to match any of the classes, and you just teased all of the classes out). And so you delete it. No problemo dude. And then you commit it and push it up to the remote (because your working in git).

And now, well now all of the history that you had in commit messages is gone for every class that was in the original file. It's not like renaming a file in git. You can always use the `--follow` flag on the current file you have to retrieve the full commit history for that file.

git log --follow path/to/filename 

Unless your a good tracker, chances are you're not going to re-discover where those commit messages went for the deleted file. Perhaps you'll never need to. I hope so.

Commit messages are a blessing for both me and my fellow developers because they are in some part a diary of what we were thinking about when we made changes. I've been getting more and more accustomed to making rather large commit messages lately. I'm recording more of the thoughts that I had around the design choices I've used, and perhaps even recording patterns I used in the commit.

The history of changes to a class is important to me. Maybe I've found some religion on this issue, and most probably, I'm going to be more prudent on keeping... one public class per file come Monday.

References:
Brad Abrams - Design Guidelines, Managed code and the .NET Framework
- Source files should contain only one public type, although multiple internal classes are allowed

Friday, November 20, 2015

Monday Night Rituals

Monday nights for me have a ritual on them now. I say now, but in reality they have had a ritual on them for several years now. Several years seems about the right amount of time to actually claim something as a ritual I suppose. It's for sure past the 66 days it takes to formulate a new behavior.


Anyways, the ritual is I meet up online at 10PM Eastern / 7PM Pacific time with a good friend of mine, Dan Gilkerson, and discuss "stuff". Mostly we chat about side projects we are working on, but it can range widely depending on what we've been involving ourselves with and who else is on the call. How do I lay out what this "stuff" is. A list would probably work best.

  1. Helpful patterns to use in meteor.js.
  2. What's a good name for our latest project idea (namecheckr is a fantastic tool to check name availability for this).
  3. Here's an idea similar to one we've had, and look someone has built a project around it.
  4. What's the latest thing Dan has learned in his latest hobby.
  5. What Kickstarter has peaked our interest lately.
  6. What's the next thing for XYZ side project we are tackling.
  7. ... A plethora of other things 
The Monday night meeting started out of a desire to make getting together and working on extra projects routine. Not only routine for us, but also routine for those around us. Being a married father of two, it can be hard to fit things in that don't revolve around the family. A routine Monday night meeting has helped in that endeavor. It's not that I don't love my family with all of my heart and enjoy spending time with them, I do.

Meeting later in the evening for me has helped with fitting things together. By 10:00PM we've gone to whatever after school activities are up for the day (soccer/dance/t-ball/kungfu), we've eaten, completed all homework, hung out, taken baths, and gotten the little angles that are my children down for bed. It gives me a good hour to decompress after the kiddos go down to sleep. My rule is to try to be done with the meeting by 11:00PM or 11:30PM at the latest so that I can still get a relatively good nights sleep.

I bring this up to say this. That if there is a side project that you intend to do, outside and beyond what you do in your day job, start with one simple ritual. Our Monday Night ritual is one of a series of rituals that I've put in place to try to make it to that next lilypad in the pond of life for getting some successful side projects flowing. You may ask, are they successful? Is anyone using them? Yes, some are. Not huge successes yet, but enough success to be able to watch people use the systems, which gives us feedback for what's next.