Tag: perspective

API: Top-Down? Bottom-Up? Somewhere in the Middle?

A Quick Brain-Dump on API Desgin

I’ll keep this one pretty brief as I haven’t totally nailed down my thoughts on this. I still thought it was worth a quick little post:

When you’re creating a brand new API to expose some functionality of a system, should you design it with a strong focus on how the internals work? Should you ignore how internals work and make it as easy to consume as possible? Or is there an obvious balance?

I find myself trying to answer this question without ever explicitly asking it. Any time I’m looking to extend or connect systems, this is likely to come up.

Most Recently…

Most recently I started trying to look at creating an API over AMQP to connect my game back-end to a Unity 3D front-end. I had been developing the back-end for a little while now, so I had a pretty good idea for how things needed to work from that perspective. The front-end? Not so much really. I knew some basic actions that I was considering, so I tried coding up an early API for them.

A lot of my focus was around how I was going to implement the code on the back-end to make this API work. It resulted in some of the API calls looking a little bit gross. But the idea was that if I settled on an API that would make the back-end easy to implement, I could get it up and running faster.

After a little while, I feel like my API isn’t getting any cleaner from a consumer perspective, and funny enough, it’s not actually as easy to implement as I was hoping on the back-end. Which had me reflect on a work example…

Once Upon a Time at Work…

Well, it was only a couple of months ago, really. I was working with a colleague on integrating a new system into an existing code base. We decided we wanted to approach the API problem from a consumer perspective. We said “let’s make this as easy to call and use as possible so that people ACTUALLY want to use it”.

We set out with this mission, and created a pretty simplistic API. The challenge? There was a lot of heavy lifting and a bit of voodoo going on behind the scenes. But you know what? We hid the magic in one spot of the code (instead of having ugly stuff scattered all over the code base) and it ended up being a very usable API.

So…

So does this consumer-first, top-down approach to API design always work? I’m not sure. Some similarities/differences in the scenarios:

  • In my current situation, I have a back-end implemented and very minimal code implemented on the caller side. In the work example, we had nothing implemented on the back-end, and a ton of code implemented where the caller side would be.
  • In both examples, at least one of the caller side or back-end side was reasonably well understood. For my game, the back-end was pretty well understood. For work, the caller side was pretty well understood and we had experience with what we’d call a “failed’ back-end implementation (that we were actually setting out to redesign).
  • The work example was a relatively small subset for an API, but the game example was about to be a very specific implementation that I’d need to adapt into a pattern for all messaging in my AMQP system

So there’s a few things to consider there. I think I’m at the point in my game where I’d like to revisit how I’m forming this API and try it from a client-first perspective. Now that I know some of the catches, maybe I’ll shed some new light!

How do you approach API design?


Article Roundup: Burn Out

Article Roundup : Burn Out

Burn Out

I had a lot of really positive feedback from my friends and family after writing about my experiences of going through burn out. If you haven’t read the post, check it out here. I’ve done some article summaries on the topic of burn out before, but I feel like it’s probably a good topic to bring up again in light of my recent post.

For a bit of background, burn out is a process that can occur to an individual that’s dedicating too much time to a particular activity. It leads to an imbalance in terms of what his or her time is put towards and can result in a person feeling depressed without any energy. Wikipedia does a pretty good job of summarizing it in one quick sentence:

Burnout is a psychological term that refers to long-term exhaustion and diminished interest in work.

With that said. please enjoy a couple of articles that I’ve surveyed from the web.

Articles

  • Job burnout: How to spot it and take action: This article is from a¬†clinic’s staff, so it has an interesting unbiased perspective. It talks about the lack of drive or interest that people might experience from burn out, which is interesting, because I personally never felt that I started to lack drive or interest in my work. Personally, it was more about losing interest/drive in other areas of my life. I also wanted to draw attention to one of the symptoms the article mentions: irritability with colleagues/clients. This one is pretty dangerous because you can actually cause some damage based on your inability to control emotions because of this. It’s worth noting that if you constantly find yourself irritated by colleagues and/or clients and have some of the other symptoms present, you might be on your way to burning out. If you’ve always been irritated by your colleagues/clients, maybe you’re just sour. ūüôā The list is pretty short, but the article does a good job of covering some of the common causes and symptoms, so it’s worth it for a quick read.
  • 10 Signs You’re Burning Out — And What To Do About It: This article by¬†Lisa M. Gerry speaks to a story very similar to my own. Our burn out experiences were really not something like working overtime for a couple weeks straight… it took years to happen, and that’s why it’s dangerous. Lisa lists several symptoms that should be familiar now if you’ve checked out Wikipedia and the previous article(s). ¬†Interpersonal problems come up again as a symptom and same with cynicism… They’re probably related. The interpersonal problems can come on multiple fronts too, whether it’s an individual removing his or herself from their friends and family, or finding that they’re getting in more arguments (or just plain not getting along) with their friends/family. Lisa goes on to list some ways to get back on track, including cultivating a rich non-work life (something I’m seriously lacking right now) and actually taking a break from work. Those are two really important things, but she lists a handful more.
  • I Came Undone: One Woman’s Horrifyingly Real Experience With Burnout: I¬†really loved this article by¬†Glynnis MacNicol because it felt like the same experience I was going through… Except I never got to the point where I quit my job. One thing I keep pointing out because I feel it’s a bit different is that most people¬†that go through burn out seem to resent their job… But I still love what I’m doing, and maybe that’s the only reason things didn’t go too far for me. Glynnis talks about being overly connected (thanks to¬†social media, smart phones, email, etc…) and how it’s a struggle to actually just go home and be away from work. Are you even able to do that in your career? I’ve always felt like I like being connected to work when I go home so I can help out when it’s necessary… but on days where I’m feeling burdened, I have to explicitly tell myself “Close Outlook. Only use your phone when you want to get a hold of someone. Close the work instant messenger.” It does the trick for me, but I suppose it’s unfortunate that “home time” doesn’t actually mean “time to not work”.
  • Burn out and chronic stress: This one is another sort of “fact sheet” on burn out and chronic stress. It re-iterates many of the same points regarding symptoms of being over-stressed and feeling burnt out, but I liked the latter portion of the listing. Specifically, the very last point on the page says to re-evaluate your priorities and goals. Many of the other posts suggest that taking time off and forcing yourself to slow down are necessary, but few of them actually say to re-evaluate your goals. I think that without re-evaluating, you’re setting yourself up for some difficult times… at least if you’re feeling like me. I know I’m starting to burn out. I know I should slow down… but if I don’t change my priorities around, taking that time off and disconnecting is going to feel like a mental burden to me. How could I remove myself from work if my goal was to get more work done? If I can re-evaluate my goals to say that spending more time with friends and family is important and that taking X amount of time off for myself is important, then it’s a lot easier to convince myself that I actually do need that time off.

Thanks for reading! If you like this post, follow Dev Leader on social media:


Burn Out

Disclaimer

I wanted to write this post to share my honest and personal experiences with burn out in the software and startup scene. I’m hoping that my experiences with getting to a stage of burn out can help someone identify if they’re going through the same thing. Hopefully someone will be able to take preventative actions before things get too serious, like I’ve been able to do. I’d also like to point out that I absolutely love my job (you’ll be reminded of that in my post) so my experience might be biased in some ways because of that. If I didn’t love what I do, I’d be finding another job where I did.

What is Burn Out?

In my earlier days at the company I work for, I remember my HR manager talking to me about burning out. It’s not unusual to pull all-nighters to work on something at a startup, and after hearing about this a few times, she mentioned to me that I need to be careful about this. She said I need to be careful that I don’t make a habit of doing things like that all the time or else I’ll “burn out”.

Now I had heard this phrase before, but never really spoke to anyone who had burnt out from too much work. From going to the University of Waterloo for co-op, I had heard about lucrative opportunities for some co-ops going out to The Valley to get jobs where they could work crazy overtime and make a killing. The idea was that on a co-op it was okay because after only four months you wouldn’t “burn out” too badly. Four months of 60-80 hour work weeks would be really intense and draining… But it couldn’t REALLY have that big of an impact on your life, right?

So that was really all I knew about burning out. 60-80 hour work-weeks for an extended period of time would result in burn out. And that meant… What? What did it mean to burn out? All I could think of was that you would become disinterested in your job and not want to work there any longer. You’d start to be tired all the time and resent going to work. You’d be an old cranky person in a potentially younger person body. Yeah, that sounds like it sucks. Is that far-off from what burning out actually is? Maybe not. But is there more to it?

Wikipedia¬†(and yeah I’m referencing Wikipedia… deal with it) defines burning out as:

“a psychological term that refers to long-term exhaustion and diminished interest in work. Burnout has been assumed to result from chronic occupational stress (e.g., work overload)”

And that looks like it chalks up to what my initial definition of burn out used to be. It also mentions this though:

“The symptoms of burnout are similar to those of clinical depression”

So that one is a bit more extreme than the symptoms I had in my mind, previously. If you keep reading the Wikipedia article on burn out, you’ll get some spoilers for what I want to continue to talk about… The point is that burn out is actually pretty serious business and it’s a little bit more than being cranky and not liking your job.

My Early(ier) Startup Days

I had (and still have) my first job out of university at¬†a company that was super small and appeared to have a really exciting future. A blossoming startup. In the really early days things were always moving incredibly fast. We’d turn¬†out feature after feature in our software, triage critical bugs into the wee hours of the morning, ensure any customer we talked to was 100% pleased in every facet of the business, and we’d be doing all of this around the clock. It was exciting, and it still is exciting to be able to take pride in doing all of those things (although, there’s less fixing of critical bugs because… we’re like… perfect… or something). Having a really fast paced environment, a team of people you love to work with, an awesome product, and an incredible mission, it was easy to get sucked right into work.

I was still a 9 o’clocker. I hated (and I still dread) mornings. I’d like to sleep until noon every day if I could. I’d get into the office around 9 and head home at 5:30-6:00ish. It might mean I pick up the odd little thing at home or do a quick investigation into a bug if I heard something in an email, but otherwise those were my core hours. This worked out really well for me when I wanted to pull a really late night to work on something cool because I could still get enough rest to come into work.

I can think back to days (and I’m only talking about a couple of years ago, not like I’m some wise old man, so take that for what it’s worth) where I’d head into the office to triage bugs that we’d consider huge blockers until two or three in the morning. I didn’t have my bosses hounding me to do this, and whether they knew it or not, I didn’t care. I had pride in what we were making so I wanted to be part of ensuring that it was of the highest quality. I’d find myself trying to churn out some extra code on weekends in my spare time when I thought of something cool related to our product or business, or just to get us a little bit more ahead.

Between hitting the gym, hanging with my friends at bars/parties, playing video games, programming my own stuff for fun, or just relaxing at home, I’d find time every now and then to program stuff for work. Again, not because anyone forced me to… but because I wanted to.¬†I wouldn’t let my gym/nutrition schedule slide during our hectic releases, and I know we had co-op students that can recall me popping out of the office for a couple of hours during crazy releases to ensure that was the case. I’ll make sacrifices into my other personal time, but ensuring I can get my gym time in is¬†sacred to how I choose to live my life. I was still keeping in touch with my friends from university even though most¬†of them moved away right after school, and I’d of course always have time for my close high school friends. Weekends were a great time to drive out (aside from having an old crappy car that was always overheating) to visit friends or have them drop in.

Early startup days were exciting and insanely busy. It was hard work but we always made sure we were having fun along the way.

… As Time Went On…

This trend kept up for a while… which was awesome for our company. We’ve received so many accolades¬†for our success and it’s great to share a responsibility in that. We’d hear back from our clients about how we were making a difference in the world, and that was more fuel to keep doing such an amazing job. I knew by then that I loved where I worked and I loved what I was doing. I had received more responsibilities in my job by this point too, so I was not only programming but I became a people manager (which was an entirely new experience for me). There was more (and very different) work being introduced for my day-to-day activities, but it continued to be an exciting journey.

There were fewer late nights to triage bugs because we adapted to have much better systems in place. There were more people that knew different parts of our code base so I could rely on other people to help out. It was reassuring to know the right people were being brought on in our company to help out with all of the different pieces. Even though I felt like I had more work to do, the responsibilities were shared on some of the big pieces that I didn’t want to be entirely responsible for. That was a bit of a relief. The difference was that now I had to know the status of more things, which added pressure.

I started to be a little bit more distant with my friends. I think it’s a natural thing to happen after university (just like it was with high school) where some of your closer friends start to go off in different directions. It’s part of life. You can keep your close friends close, but you always know that you can catch up with your for-life friends even if you’re apart for long periods of time. Okay, let’s not get all emotional on the friend-front. I noticed that I was starting to put off visiting friends for certain work things at this point though. For example, if I had a big release I might skip someone’s birthday because I knew I had a stressful weekend coming up, and of course it didn’t help that we had a milestone with some project that was following right after too. I was trying to find ways to make it up to my friends for missing things because I felt bad about it.

My hobbies started to narrow a bit by this point. I’m still an avid gym goer, and I was during this time frame as well. I was going every single day like I had planned… even during those hectic releases. I was playing video games less because they weren’t really something that was productive. If I noticed I was spending a lot of time on video games, I could often convince myself that there was work to do that would have a positive impact if I could deliver it. Do I need to level up my digital wizard character again in some fantasy land that doesn’t mean anything, or could I knock off another feature from our roadmap? It’s not that hard to change your mind when you like what your building, so the choice would often come down to “what’s more productive”? This is also coming from a person who doesn’t watch TV ever because it doesn’t feel productive, so maybe I’m just weird.

After a couple of years of startup life, I was still loving it. Certain parts of my life were changing (less time for friends and hobbies… more and varied responsibilities at work), but the positives still outweighed the negatives. Besides, it feels really good to be productive.

And Now…

It’s been a few years now, and yes, I still absolutely still love my job, what we make, who I make it with, our customers, and all of the crazy things we go through. If you talk to anyone on my team, they’ll let you know I’m a morning person now. Except that I’m really not. I actually hate waking up early, but rolling out of bed at 7 to get to work for 7:30-7:45 means that I get some extra time in the morning to work. My team would also let you know that I work late too, so if you needed to pop into the office because you forgot something, you could come by my desk and chat with me. My core hours aren’t 9-5 anymore, but they’ve evolved to be about 8 to 6. If I’m not at the office by 8, some of the early risers actually get worried about where I’m at. If I’m out of the office before 6, people will ask me what’s wrong because if I’m leaving “early”, then something must be up.¬†I don’t really take vacation now either. I’ve been bothered (for what I believe to be all of the right reasons) by my HR manager to take more vacation than I do. And yeah, this is the same HR manager that mentioned the burn out thing to me. I don’t really take vacation now because it chews into my work time.¬†Work often carries over into the weekends too. I’m working those Valley hours now trying to get as much productivity as I can in my 24×7 window.

My job responsibilities? They’ve shifted to encompass more things, which feels great. It feels good to put in time and be able to take on more responsibilities. However, with more responsibilities comes more accountability for things (obviously) which can mean pressure build ups when certain things align. For example, instead of being responsible for a single project or deliverable, I might be responsible for two to four of these things. If they happen to line up in a short period of time, it can mean an immense amount of stress. It can also mean that I don’t feel comfortable taking vacation during those heavy periods. Unfortunately, the more prolonged that goes, the more I need vacation and the more I feel like I can’t take it.

My hobbies are really narrow now. I hit the gym every day still. I’m still adamant about this. However, my nutrition has been starting to slack. I enjoy eating healthy, preparing food, and knowing what I’m putting in my body. The¬†latest thing to give way is food preparation ¬†because it takes time, and it’s easy to get food in other ways. I’m not really proud of this or happy with this. Video games? I’ll take a day every now and then and binge on them to blow off some steam. Hobby programming? Not a chance. Blogging? Look at the frequency of my posts as of late to get an idea… It’s trailed off. ¬†My current frame of mind seems to revolve around the idea of “if it’s not work, I probably shouldn’t be doing it”.

My friends? I feel like I only have my closest friends still and my colleagues (and I love my colleagues like family, so that’s not a bad thing). I’ve done a really poor job of keeping in touch with everyone else because I’m not making any time for them. I’ve been doing a pretty bad job of keeping in touch with m y immediate family too. I didn’t even realize it until my parents started pointing it out, which is obviously¬†a problem.

So What’s Going On?

Right now I’d say thing in my life probably aren’t what I would consider great, despite the fact that I’m living to all of the goals that I’ve set for myself. I’ve graduated from university with a degree studying computer engineering. I have a full time job that I love and work hard at. I have a car that I like. I have a condo that I love. Why aren’t things great?

I’ll direct us back to Wikipedia for this interesting little list they have. They’ve actually defined a list of the stages of burning out, and I can speak to a lot of them in the order that they present them:

  • The Compulsion to Prove Oneself: New to the workforce. New to the job. New to the team. I saw great potential in the company, and I wanted to prove that I could be a driver in getting it to where it could be. I needed to prove to someone (myself? I don’t even know) that I could be that driving change. Could it be done without me? I’m sure my team could have gotten to where they are without me because they’re all¬†talented people, and I didn’t bring anything to the table that they couldn’t have made up for. But I wanted people to look back and think that I was a primary driver in all of this.
  • Working Harder: You can likely see it in the transitions I described above. I’m not a morning person, but now I wake up early to get more time for work. I stay up later to get more time in for work. I trade out my hobbies so that I can make time for work. I have tried to find any way I can to increase the amount of work I can get done.
  • Neglecting Their Needs:¬†I’ve probably been in denial on this one for a long time. I try to be as healthy as I can… But I’m neglecting my need to sleep sufficiently. I’m neglecting my need to spend time with friends and family. I often look at my “needs” as biological (good food and exercise) and my ability to keep a roof over my head. I’ve been neglecting the other pieces.
  • Displacement of Conflicts:¬†This is apparently the stage when people first start to realize something is wrong. Is that why I’m writing this post in the first place? Am I only at this early stage of burn out? I feel like I’m showing traits of some of the following steps though.
  • Revision of Values: When reflecting on my current state compared to how I viewed myself at the end of university, I know things have changed. My highest valued trait is my ability to do work. If I don’t work as much or as hard, I value myself less. I’ve certainly become more emotionally blunt as well. Over the past few years, I’ve been referred to as robotic more and more frequently. Other people are noticing this too, so it’t not just me.
  • Denial of Emerging Problems: My¬†personality type tends to ride the line between introvert and extrovert on certain things. I can tell that my ability to be extroverted has become extremely demanding on me mentally/emotionally and that often means that I’d choose to be alone versus with a group of people. The article also states increased amounts of aggression and sarcasm are present. For anyone that knows me well, sarcasm is my middle name… And when I’m irritated, sarcasm becomes my weapon of choice (which is really unfortunate). I also blame all of this on the amount of work that I have and pressure that I believe I’m under. I don’t blame any of this on how I’ve changed my value systems over the past couple years, which isn’t fair.
  • Withdrawal: I’m not quite sure if I’ve totally hit this step, but this really just refers to an increased level of wanting to be removed from social interactions.
  • Obvious Behavioral Changes: I suppose this is for other people to observe. I’ve picked up a few cues that other people are noticing I behave differently. An example is my reduced emotional intelligence and tolerance for certain things I don’t find logical at face value. I generally get irritated by this kind of thing¬†and then turn to sarcasm.
  • Depersonalization: This point was interesting. While I don’t think that I’ve devalued myself or others necessarily, I do think that I view my life as a series of mechanical functions. It’s a rather boring way to look at life, but I’ll admit I look at things as a regular process and I look for ways to optimize my time to get more work done. The amount of work I can get done is how I determine my efficiency, and my life currently revolves around being more efficient.
  • Inner Emptiness: I think I’ve arrived close to this point, personally. As I mentioned above… I’ve set a few personal goals in my life: education, good job, car, and place to live. I feel that I’ve¬†achieved those things, and I’m always working to improve in those areas. I still feel completely empty in terms of achievement though.
  • Depression: Next up? Depression. The great news is that I don’t feel depressed. At all. There’s a history of depression in both my mother’s and father’s sides of the family, so this is a fear of mine. I’m worried about falling into a depression, but I don’t believe I’m there yet. I actually think I’m a long way off from it. I think as far along into burning out that I might be, I can take the necessary steps to avoid getting to a depressed state.
  • Burnout Syndrome: This is the final stage that involves collapsing physically and emotionally. While I do have a feeling¬†of emptiness, I’m still quite physically healthy and I think I have the right frame of mind for how I’m looking at my state of burn out. With that said, I’m quite confident that I’m not at this stage.

I’d¬†encourage you to actually check out the article on this because it’s pretty interesting; especially if you think that you’re on your way to being¬†burn out.

I haven’t been totally oblivious to what’s been happening over time. Here’s my own list of the things I’ve picked up on:

  • My emotional intelligence has been slipping and I’m always thinking in a more logical manner, often neglecting the feelings of others. I’ve had a few instances come up where I’ve said the wrong thing because I wasn’t really offering support for a friend, but instead telling them what I thought based on my more robotic personality.
  • Being around people is draining. I hate to admit this one, but I find spending time around other people is draining. Spending time around people I don’t know for a night might mean that I don’t feel like hanging out with anyone for a week or more.
  • I’m becoming socially challenged. When I need to meet new people, I don’t really know what to say anymore. I don’t have all that much to talk about now. I’d rather just be alone. Sure, I might be a programmer so people expect that my social skills aren’t up to average,¬†but I’m actually noticing that I don’t know how to interact with new people now. It’s¬†scary. You might not observe it if you meet me, which just means I’m doing a really good job of hiding it because that’s how I feel about it.
  • I have one hobby, and it’s lifting weights. Unfortunately, I happened to pick one hobby that not a ton of people find that exciting. I don’t make time for creating music anymore. I don’t hobby program that often. I rarely play video games. I don’t feel like I have time or interest to go pick up anything new.

The Silver Lining

If you’ve made it this far without clicking away, falling asleep, or both, then it probably sounds like a pretty lame¬†post about my life. That’s not the goal of it though, and that’s certainly not how I feel about my situation. I’m actually just trying to understand all that’s going on with regards to going through burn out. With that said, I think there’s a handful of really positive things I’ve picked up on over the past few years with respect to this:

  • I’ve learned how I work most efficiently. I’ve had to work in a variety of scenarios on a variety of different projects. I know that I like working mostly in isolation or if I’m part of a team, then working around just those individuals. I like having distractions of my other responsibilities removed (which for my career, is often tricky given that I interface with many different people). I know that I like having some music going and being able to crank out code without interruption. I like to stay well caffeinated, and I like working in the evening more than I like working in the morning. I’m a¬†typical programmer.
  • I’ve learned that I love working with the people at my office. Call it corny, but I have my work family, and I love to work with them. They have a high level of trust in me, and I’m able to trust them. It’s a great dynamic and I’m glad I’ve had the opportunity to work with so many great people.
  • I know that given enough time, I can work through most problems no matter how difficult they seem. I’ve had to come up with some really unique solutions to problems I originally thought near impossible.
  • I consider myself the hardest working individual that I know. I pride myself in this, but… perhaps that’s the whole problem here ūüôā

What’s Next?

That’s the big question here. I’ve identified that I’m well on my way to burning out… So what’s next for me? If you’re going through something similar… What’s next for you?

  • Spend more time with friends. Hands down. Number one priority. I’m going to start making more time for friends. ¬†If they’re out of town, I’m going to start offering to drive out to visit them more often if they don’t feel like making the journey here. Same goes for family. I’m getting regular Skype sessions set up with my family so we can stay in touch between visits. Friends and family are one of my needs that I’m neglecting, and I’m going to remedy that first.
  • Vacation. I used to believe I lived the work-hard-play-hard lifestyle, but it’s just the work hard lifestyle now. It’s time to take some vacation and acknowledge that I need it in order to actually stay sharp and operate at the best of my ability. Taking vacations and having time for yourself (and/or your friends/family) is hugely beneficial. Just because it doesn’t let me turn out more lines of code doesn’t mean it’s a bad thing.
  • Tell my HR manager she’s been right for a long time. And this will be my first step in seeking some external help. The first step is admitting the problem… and the next step is getting help for it ūüôā

I’m keeping my list of goals pretty short for now. I need to start making changes in how I operate and then reassess how these changes are affecting my life. I’m expecting positive changes, but I’m not sure how fast.

If you think you’re¬†on the way to potentially burning out, I think the most important thing you can do is be aware of it. I still don’t believe there’s anything wrong with working hard and pouring your heart into something you love doing. But like anything, the more time you dedicate to something and take away time from other places, you’ll find that it starts to change the person that you are. Pay attention to it. Be aware of it. It’s all that you can do to prevent yourself from getting to a state where you feel like it’s too late for you to make a change.

It’s never too late for you to work your way back from burning out.


One on One Evolution

Background

I’m a “middle manager” where I work, but that means a whole bunch of things. My everyday tasks primarily consist of programming, but I do a bunch of work to interface with other departments and teams, and I play a role in managing people on… well, the “people” side of things. For the latter part, I refer to that as people leadership.

I think it’s pretty easy to look at some of the aspects of people leadership and dismiss them as “fluffy” or needless… I consider myself a logical/technical thinker, so I have that frame of mind¬†sometimes. However, I do see the value in¬†actually being able to support my¬†team so that they can operate at the best of their abilities. I try to find ways to do that without it seeming to them like I’m doing “fluffy leadership things”, and in turn, I don’t feel that way about it either. With that in mind, I had previously set out with ways to accommodate team feedback in a way that works best for them.

One on Ones: The Early Days

I worked with my HR manager a couple of years back to establish a one on one template that I could use with the developers on my team. The goal was to be able to identify points of conversation since the last time we met, the individual’s current situation (both positive and concerns), and then identify goals. Ideally, the individual is able to fill this out on the form in as much detail as necessary for us to be able to have a conversation about it later.

I didn’t want this to seem like a chore for people so I’ve tried to identify why this is useful for the individual and for myself. For the individual, it gives them an avenue to discuss anything that’s becoming a problem over the period of a few weeks (i.e. something not obvious all at once) or be able to identify successes in their work. It also allows them to reflect on their goals that they want to set in their career, current projects, or even things outside of work (because¬†improving your abilities outside of work is a good thing too). For me, it provides¬†better insight into the¬†trend of problems people are experiencing, their contributions to their current projects, and even helps me see where people are at with their career goals. Both parties are able to benefit from these!

I’ve left it open in the past as to how people submit them. Written? Sure. Digital? Sure. Whatever is easiest for the individual provided I can get it a couple of¬†days before we meet. I’ve also left it open ended as to how much of the form they fill in. Based on the trends, I think people see value in having more content but sometimes the goal setting is a bit of a grey area. People might be between setting different goals and want to wait to discuss those things. The best part is, I don’t need to hassle the team to fill in more… They just do a great job of providing information for me!

One on Ones: Continuous Improvement

I’m all for continuous improvement in our development¬†processes that we have as well as our management processes. With that said, we’ve made a few tweaks to the one on ones recently that I think have had a great positive impact.

  • Digitized: I’ve got everyone on board with digitizing their one on ones. This is incredibly handy for being able to search for content later on (instead of sifting through paper), so I get a huge benefit from it. Each individual can probably benefit from this too if their ever looking for things we discussed. Archiving digital documents¬†has so many benefits over the paper counterparts that it’s hard to imagine going back to these mostly being paper-based. I can easily print off copies for the individual if they lose them (or if I lose them) and it makes life easier for me at year end. I can quickly scan over documents on my computer to get a good overview of a person’s year right on my laptop.
  • Nick’s Notes: A little tweak to the one on one process is that with the digital copies, I can put in highlighted notes. This allows me to get down my feedback to the individuals before we meet. In the past, I requested documents a couple of days before we meet so I can try to action what I can ahead of time. However, adding my notes and getting it back to the individual before we meet let’s them know things I want to dive deeper on. It gives them an opportunity to prepare their thoughts, and from what I’ve heard, this is really beneficial for them. The other positive thing is that it let’s me provide them kudos on certain things that I don’t necessarily need to spend a lot of time talking about them with one on one. It’s improved the efficiency of our meetings, and I think it benefits both sides.

What’s Next?

I’ll be honest in that I don’t have any next steps planned for these one on ones. But that’s okay! I’m going to let a few more rounds of these go through before I try to tweak the process. This let’s me get a feel for how the changes are playing out and then from there I can see where I might need to make some improvements.

If you don’t have a semi-structured system in place for your one on ones, I highly recommend it! Make it something you can at least get a feel for how successful they are. If you can gauge their effectiveness, then you can try to tweak the process over time to improve¬†it! You’ll benefit from the information, and your team will benefit from you providing support for them.


ProjectXyz: Enforcing Interfaces (Part 2)

Enforcing Interfaces

This is my second installment of the series related to my small side project that I started. I mentioned in the first post that one of the things I wanted to try out with this project is coding by interfaces. There’s an article over at CodeProject that I once read (I’m struggling to dig it up now, arrrrrghh) that really gave me a different perspective about using interfaces when I program. Ever since then I’ve been a changed man. Seriously.

The main message behind the article was along the lines of: Have your classes¬†implement your interface, and to be certain nobody is going to come by and muck around with your class’s API, make sure they can’t knowingly make an instance of the class. One of the easiest ways to do this (and bear with me here, I’m not claiming this is right or wrong) is to have a hidden (private or protected) constructor on your class and static methods that let you create new instances of your class. However, the trick here is your static method will return the interface your class implements.

An example of this might look like the following:


public interface IMyInterface
{
    void Xyz();
}

public sealed class MyImplementation : IMyInterface
{
    // we hid the constructor from the outside!
    private MyImplementation()
    {
    }

    public static IMyInterface Create()
    {
        return new MyImplementation();
    }

    public void Xyz()
    {
        // do some awesome things here
    }
}

Interesting Benefits

I was pretty intrigued by this article on enforcing interfaces for a few reasons and if you can stick around long enough to read this whole post, I’ll hit the cons/considerations I’ve encountered from actually implementing things this way. These are obviously my opinion, and you can feel free to agree or disagree with me as much as you like.

  • (In theory) it keeps people from coming along and tacking on random methods to my classes. If I have an object hierarchy that I’m creating, having different child classes magically have random public APIs changing independently seems kind of scary. People have a harder time finding ways to abuse this because they aren’t concerned with the concrete implementation, just the interface.
  • Along with the first point, enforcing interfaces¬†makes people think about what they’re doing when they need to change the public API. Now you need to go change the interface. Now you might be affecting X number of implementations. Are you sure?
  • Sets people up nicely to play with IoC and dependency injection. You’re already always working with interfaces because of this, now rolling out something like Moq or Autofac should be easier for you.
  • Methods can be leveraged to do parameter checks BEFORE entering a constructor. Creating IDisposable¬†implementations can be fun when your constructor fails but and your disposable clean up code was¬†expecting things to be initialized (not a terribly strong argument, but I’ve had cases where this makes life easier for me when working with streams).

Enforcing Interfaces in ProjectXyz

I’ve only implemented a small portion of the back-end of ProjectXyz (from what I imagine the scope to be) but it’s enough where I have a couple of layers, some different class/interface hierarchies that interact with each other, and some tests to exercise the API.¬†The following should help explain the current major hierarchies a bit better:

  • Stats are simple structures¬†representing an ID and a value
  • Enchantments are simple structures¬†representing some information about modifying particular stats (slightly more complex than stats)
  • Items are more complex structures¬†that can contain enchantments
  • ¬†Actors are complex structures that:
    • Have collections of stats
    • Have collections of enchantments
    • Have collections of items

Okay, so that’s the high level. There’s obviously a bit more going on with the multi-layered architecture I’m trying out here too (since the hierarchies are repeated in a similar fashion in both layers). However, this is a small but reasonable amount of code to be trying this pattern on.

I have a good handful of classes and associated interfaces that back them. I’ve designed my classes to take in references to interfaces (which, are of course backed by my other classes) and my classes are largely decoupled from implementations of other classes.

Now that I’ve had some time to play with this pattern, what are my initial thoughts? Well, it’s not pure sunshine and rainbows (which I expected) but there are definitely some cool pros I hadn’t considered and definitely some negative side effects that I hadn’t considered either. Stay tuned

(The previous post in this series is here).


Quality & Agility in Software: Session With Paul Carvalho

Quality & Agility in Software: Session With Paul Carvalho

Quality And Agility

Last week, at Magnet Forensics we were fortunate enough to have a very talented quality expert come in and talk to us. Paul Carvalho was able to bring a great deal of information, perspective, and activities to our development team that truly proved to be an eye opener. We were all extremely excited to get to sit down and hear what Paul had to say.

There’s lots to read about Paul over at his STAQS site, but I’ll re-iterate some of it here. Paul has held many roles when it comes to software development. He’s been a developer, a manager, a tech support person, and part of quality assurance. He certainly has a full perspective on software development. Coming from a science background, he does a great job of explaining why things are a certain way or why you’ll expect results given some conditions. This made understanding his approach to quality and software much easier for me to get a handle on.

It felt like we covered so much, but I want to provide a high level of the take away points that really stuck out for me.

Quality: What Is It?

Paul started us off by getting us to describe what quality means. In the end, we arrived at something that provides value (where value is actually defined) to an audience (again, where audience is actually something that’s defined). So what does that mean? Quality is dependent on who and what you’re talking about, so it’s important that when you’re trying to deliver quality that you are all aligned on what exactly quality will mean.

To illustrate his point, Paul had us perform an exercise where we really only used one method of communicating some information to our partner. The result of the activity proved that even when sitting right beside your partner, you can lose a ton of information in how you communicate. So having tickets written up or having a one way communication channel is almost guaranteed to cause some misunderstanding when it comes to expectations. Part of the solution? Converse. Actually have the person describe back to you what you said. This way, you both start to hone in on what your expectations are. It was a cool exercise, and it definitely proved his point.

Perspective

We also discussed perspective a lot in our session with Paul. He had examples where simply altering your (physical) view point on something would cause you to describe something completely different. From there, we drew parallels into our software development process. There’s the old “but it builds on my machine” scenario that mirrors this really well. Paul really wanted to drive home that product owners, developers, and testers all have different perspectives on things so we need to get on the same page to ensure we can deliver quality.

Paul also asked us what seemed to be a really simple question, which for a few of us meant that it actually had to be a loaded question underneath the obvious. By showing us something on the TV in our board room, he asked us if what was being shown was a particular object. The easy answer sounded like “well, duh, yes”, but he was driving home a huge point on perspective. We weren’t looking at the object, we were looking at a TV showing a digital rendering of a piece of artwork that depicted some object. The answer was kind of abstract, but it was really cool to have that conversation about what you’re really looking at.

Awesome Agile Activity Alliteration

As a team lead, there was one activity I found absolutely awesome. I’m hoping everyone got the same take away form it that I did. Paul had us work as one big group to perform some activity. The goal was to circulate as many balls through every individual in the group as we could in two minutes. There were a few rules that I won’t bother explaining, so it wasn’t necessarily that easy.

Quality & Agility in Software: Session With Paul Carvalho (Image by http://www.sxc.hu/)

Having 15 people shouting and debating in the first planning portion made things pretty tough, but we came up with a workable solution. Paul made us estimate how many balls we thought we could get through, and we felt so poorly about our design that we said only four. We tried it out, and managed to get about 20. Awesome!

We were told to do another iteration, and he gave us another mini planning session. Again, the shouting and mayhem ensued, but we wanted to tweak our first approach. We finally organized, and when we tried it out, we doubled our initial throughput. We were onto something. The next planning session, the shouting was a little less, and we added a few more tweaks. We noticed the following problems from before:

  • We were moving too fast, so balls were dropping.
  • We were only moving one ball between people at a time.
  • Our throughput was nearing the limit of how many balls we had.
  • Our counting was extremely poor.

Solutions? Slow down. Move two balls instead of one, which should be easy if we’re going slower. Recirculate the balls instead of putting them back in the container. Dedicate one person to counting that wasn’t me (the person who would either inject more balls or get them from the end to recirculate). We shattered our previous record, nearly doubling it again.¬†Next planning was similar. We addressed some minor pain points and decided to go for a whopping four balls at once. We added another 25 to our throughput, so we were sitting around 100.

At this point we realized we were nearing the potential maximum throughput for this design and given the time restrictions for planning, we couldn’t generate much to improve upon. We debated a completely different approach for a bit, and realized it was going to be unrealistic–but this added to the takeaway.

So, with that said, what WAS the takeaway from this activity and why did I like it so much?

  • The activity is a direct parallel to our sprints. The balls are the features we’d be developing.
  • The planning process was hectic. Everyone was involved and generated great ideas, but it took a select few “leaders” to actually pull triggers. Otherwise, nobody would agree on ANY of the great ideas we heard.
  • Dropping a ball was equivalent to a problem sneaking through or something not getting done. In terms of quality, this was like a customer seeing a bug. The more people that touched it likely meant that the bug would be smaller or have less of an impact. A cool little quality parallel.
  • We need to be continuously improving. We should leverage our retrospectives¬†to improve our process. It’s important that we keep experimenting with our process to see if it can be improved.
  • There will be a point where we think we can’t improve anymore with our current process. If we’re not happy with throughput, it may require a completely different approach.

Summary

The whole team thought having Paul in was great. We have a ton of things to take back to the drawing board to use and try to improve our processes. I think it’s safe to say any one of us would recommend consulting from Paul. His insights are excellent, he conveys his thoughts clearly, and he has activities that are so incredibly aligned to the points he’s trying to get across.

I’m looking forward to using Paul’s techniques for improving the quality in our software and the processes we use to develop. Thanks again, Paul.

Links


Lead by Example and Emulate Ideal

Lead by Example and Emulate Ideal (Image by http://www.sxc.hu/)

Background

Leadership has become a big focus for me as I start to grow more into my role at Magnet Forensics. As a developer, I feel like it’s easy to gain basic knowledge and experience with unfamiliar programming territory just by surfing The Internet. With leadership, that’s certainly not the case for me.

What’s my most recent realization? Lead by example if you expect anyone to take you seriously. As a young leader (and with little professional experience in a leadership role), I think this becomes especially important. When you lead by example, you’re showing others that you’re really behind what you’re preaching.

Lead by Example: A Simple How-to

Maybe it’s obvious, but I really don’t think I’m over simplifying my message when I say it. To lead by example, you just do what you expect other people to do. Obvious, right? If you’ve been working for long enough, you’ve probably had a boss that you thought was doing a poor job. There’s many reasons for this, and I don’t want to turn this into a negative-dwelling-unhappy-rant party, but one such reason is it felt like they were just passing down orders to you.

What’s more disengaging than having someone that’s locked up in a room come out every couple of hours to assign you a new task? This boss of yours was doing a poor job of demonstrating meaning to you. Why was doing what he or she was telling you to do was the right thing-the thing that’s going to help get the company to the next step? He or she was not using what I would now call leadership rule #1: lead by example.

Okay. So you’ve envisioned the times when it sucked. We’re off to a good start, because hopefully things can only look up from here. What would you have done differently if you were in your old boss’s shoes and you wanted to inspire an alternate-universe-you to do a good job? There’s probably a handful of things you can think of (and for certain people with certain bosses, maybe that handful is multiple gorilla-sized handfuls).

What if your boss, your manager, or your leader had actually sat down with you and guided you through their expectations? What if the first time through a particular task you sat together and worked through it as a team? What if there was nothing left unclear and you could truly get behind what you were being told? I’m sure you wouldn’t feel resentful of the almighty boss throwing down orders like lightning bolts from the heavens if that was the case.

But why? Here are a few reasons:

  • The clarity of expectations becomes established. There’s a lot less guessing work. Being able to establish clear expectations at work is key to building trust and having successful teams.
  • You buy in. When someone can lead by example, they’re proving to you why they value something. It’s a lot easier to get behind them compared to someone else who has never proved their knowledge, skills, or experience to you.
  • It becomes more like a peer relationship when receiving work. Initially, you feel like you’re shadowing someone that you can more easily relate to. When it comes time to take the reins, you don’t feel like you’re pulling your manager in a carriage behind you.

Emulate Ideal

As a leader, you’d be shocked if you realized just how much of an effect you have on other people. You don’t have to be the CEO or manage 100 teams of 100 people to have the influence either. The even more surprising part? A lot of your influence is actually not a conscious effort on your part. Boom.

The reason I’m suggesting that as a leader you should be emulating ideal is because people will pick up on it. People see how you act, whether good or bad, and will learn to emulate your own behavior. If you’re a hard worker who gets things done, your teammates will learn that that’s what drives the team’s success. If you’re always putting down people’s work, then it will be the norm for nobody to really have an appreciation for the work of others. If you’re watching YouTube and surfing the net all day, that’s now acceptable behavior for everyone else. Repeatedly show up late for or flake out on meetings? Don’t be surprised if meetings become less effective. Constantly encouraging people and acknowledging their successes? You’ll start to see others praising each other. These might be generalizations of course, but if everything else is aligned I’m sure you’ll see these kinds of trends.

This truly is often overlooked. Once you’ve gained respect from people and you have their attention, your actions will have a big impact. So now instead of expecting your team members to act in accordance of what you think is ideal, why not live it out yourself? They’ll automatically start making the transition, especially if you’ve clearly communicated your expectations to them.

Summary

You get the most buy in from others when you lead by example, and you’ll become much more effective as a manager or leader. You have your own expectations of what ideal is, so it’s important to communicate them with your team (Side note: expectations go both ways. Make sure your team’s expectations of an ideal leader are properly communicated to you). One of the best ways you can communicate your expectations through leading by example regularly, and you drive the point home by emulating your definition of ideal.

Extras

If you’re looking for a bit more on how and why to lead by example, consider these links:


v6.2 of IEF from Magnet Forensics! – Weekly Article Dump

IEF v6.2 from Magnet Forensics

v6.2 Release: Mobile Forensics Upgrade

I like to be able to use these weekly article dumps for little summaries of what’s going on in my work life, and I think this is a perfect opportunity to acknowledge our latest product update at Magnet Forensics. We just pushed out v6.2 of Internet Evidence Finder and we’re incredibly proud of the work we’ve done. Like any release we have, we pour our hearts into making sure it’s a few big steps forward. We’ve done our best to listen to customers and work with them to address any bugs, but we’re always trying to push the boundaries in our features.

Some of the new offerings in v6.2 of Internet Evidence Finder include:

  • Dynamic App Finder: We now offer a solution for recovering mobile chat applications that we may not have otherwise supported. This is a great discovery tool and has proved to be very powerful even in our early tests. Read more about it here. v6.2’s secret weapon!
  • Chat Threading: Visualize chat threads within our software as they look in their native applications. If you’re looking at a Skype conversation between two or more people, it will show up just like it does from within Skype. A lot less jumping between records to piece together a conversation.
  • L2T CSV Support: L2T CSV files can now be loaded directly into our timeline viewer.
  • Case Merging: Combine multiple IEF cases together or pull in data from TLN/L2T CSV files.
  • More Artifacts: v6.2 is no different than previous releases when it comes to adding new artifacts!
    • AVI carving
    • Hushmail
    • TOR chat
    • Flash cookies
    • Offline gmail
    • Additional Chrome support
    • … and more.

If you’re a forensic investigator, v6.2 is going to be an awesome upgrade or addition to your suite of tools. If you’re not, then check out Magnet Forensics to see what we’re all about and so proud of what we do. Congrats to Magnet on an awesome release of v6.2!

Articles

  • In praise of micromanagement: I’m still very early on in my career, so it’s difficult for me to have an opinion on this article and back it up. It’s a bit controversial, so of course I want to take the other side and disagree with it.There’s that, and I have some discomfort when it comes to Apple so I like to turn off when I see articles on Apple or Steve Jobs. Regardless, I thought that there was an interesting perspective in this piece to share, and maybe even if I can’t see it right now, others would benefit from reading through it. Is there a place for micromanagement? Can it be done right? Are people like Steve Jobs just an exception to an otherwise good rule?
  • The Myth of the Rockstar Programmer: Scott Hanselman¬†says that rockstar programmers don’t exist–rockstar teams do. I completely agree. When your company is so small that you essentially don’t have teams, this might not hold. Maybe you have three developers and each one is a rockstar in their own right. That’s probably a it different. More often than not, you’re not working with one or two people developing a product for a company. It’s not about having one rockstar with all the programming super-powers take charge on the team. It’s about creating a team where everyone has their own strengths and weaknesses and then organizing them to operate at full efficiency. Teams. Not individuals.
  • Strengthen and Sustain Culture with Storytelling: This is an article that I can really align myself with.¬†Nancy Duarte¬†writes about something that’s often lost when small startups are transitioning into small businesses. It’s entirely possible some companies don’t even make it out of the start up phase because this thing is already going south. Storytelling. It’s important to be able to share stories with people as you bring them on board to your company. They need to know where the company has been and how it’s gotten to where it is. New hires need to feel like their part of the family as they are brought on board, and without conveying your company’s mission and values properly you start to lose that alignment.
  • Ignoring Your Test Suite: Another programming article here, but this post by Jesse Taber¬†has some deeper lessons to be learned, in my opinion. The article talks about something not all programmers do, but should: write code that tests their code. This lets developers catch problems early on (because catching a problem now might cost a bit of time, but catching the problem later could be devastating). Running code tests regularly is a process that allows you to ensure the foundation of your software product is structurally sound. But what happens when you have flaky tests? What happens when you introduce a new failure and don’t bother to fix it? After all, you have 3000 tests, and you know why test ABC is failing anyway. Don’t put processes in place just for the sake of having them. Everything you do should be done for a reason, because your business doesn’t have time for anything else. Don’t enable poor habits. If you’re noticing problems in your process, identify why they are happening and look to get them fixed. Maybe you need to adjust your process because it doesn’t fit anymore.
  • Cameron Sapp ‚Äď Recognizing The New Guy: This one is from me. I wrote up a little recognition piece about a colleague and teammate, Cam Sapp. I want to be able to write more recognition posts, but I started with Cam. He’s been a great addition to our team both from a technical and work culture perspective. All of Magnet is glad to have him on board.
  • Don’t Work For Your Boss, Work For Your Company: I thought that¬†Ilya Pozin¬†had written something great when I cam across this article. Hierarchies in the workplace can often cause disconnect and disengage employees. So why do we have them? I’m not against hierarchies–I think they serve a purpose. However, I think necessary measures need to be put in place to ensure that hierarchies aren’t detracting from the company’s goals. In this article, Ilya says to not work for your boss. Your goals at work should not be to satisfy individuals or only do things for your boss so you can get your promotion. Align yourself to the company values and the mission of the company. You’ll remain engaged and happy to do the work you’re doing. In the end, if you’re not happy doing work that’s aligned with your company’s mission, vision, and values, you might be in the wrong place.
  • Creativity and the Role of the Leader: This article discusses where ideas come from and how leaders fit in to the grand scheme of things. The traditional mindset is that ideas come from the top and then are pushed down to employees to carry out the work necessary for bringing the idea to fruition. However, it’s increasingly more common where ideas are actually generated by employees, and it’s the responsibility of the leader for nurturing idea creation and ensuring that ideas that are aligned with the company’s mission can succeed.
  • Will Your Firm Endure?: In this article by¬†Tim Williams, I took away two key points. In order for your business to be absolutely sure it can endure, everyone needs to be viewed as replaceable. I don’t mean in the sense where we can trade John for Joe and not care because we don’t value human qualities, I mean strictly from the skills and responsibility aspect. There shouldn’t be instanced in your business where if an individual were to disappear one day your company wouldn’t be able to carry on. The next is acknowledging strengths and weaknesses. When people have some obvious strengths, they have weak areas too. There’s nothing wrong with that. It’s normal. Make sure your teams are constructed of people with complementary skills.
  • Dynamic Programming with Python and C#: Another article from me, and another programming related post. This my follow up to a post about C# and Python integration¬†that seems to have been received really well. It was a cool little experiment for me to take Python and C# and have them working together in my favourite IDE, but on top of that, I was actually able to learn a bit about C#’s “dynamic”¬†keyword which was new for me. If you’re familiar with either of C# or Python I recommend checking it out. There’s some pretty cool stuff you can do, and I’ve only scratched the surface.
  • To Find Success, Forget Your Priorities:¬†Claire Diaz-Ortiz¬†says that priorities are too general. We all have priorities, but how many of us are seeing ourselves achieve what we’d like? Claire suggests forgetting your priorities and breaking them down into goals you can achieve. By having conrete action plans, you can execute them properly.
  • Personality Tests: Modern-Day Phrenology: Ron Baker¬†shares his perspective on why personality tests don’t have a place at work. He goes as far as calling them meaningless, but I believe his main argument is that simply siloing people into personality types is pointless. To that end, I agree. I thought this article had great timing because I’ve been discussing personality tests with our HR manager at work. I came across this article right before doing a personality test with her and we decided a few things. Firstly, if the results of the test don’t make sense, then don’t go any further with it. This means that either the test you’re using is flawed or perhaps you don’t understand the test. Regardless, how can you take action on something you don’t understand? We both agreed that simply identifying traits was useless on it’s own, so I think we agreed with Ron on this one, but we weren’t stopping there. The basic act of identifying personality traits had us sparking conversations about how our personalities were different and how acknowledging these differences could influence our interactions. Essentially, it was hard to just silo ourselves into a particular personality type without thinking about and acting on what we were observing. In the end, identifying personality types and sticking someone into some cookie-cutter process for it means nothing. The tests are all about ganining insight and understanding so that we can choose where to go from there.
  • How Open Should a Startup CEO Be with Staff?: Coming from a startup, this was another interesting article. Mark Suster¬†writes a semi-controversial perspective about CEO transparency. The norm is that expecting CEO’s to share every bit of details with the employees achieved perfect transparency and makes everything better. Mark says this definitely isn’t the case and provides some excellent examples where total transparency came back to bite. It’s all about balance. Transparency is great,but total transparency is often too much for most employees to handle on a day-to-day basis.

Follow Dev Leader on social media outlets to get these updates through the week.

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+
Nick’s CodeProject Articles

You can also check out Dev Leader on FlipBoard.


Leadership Reads – Weekly Article Dump

Leadership Reading - Provided by Stock Free Images

Great Leadership Reads

Here’s a collection of articles I’ve shared over the past week on social media outlets. There’s a lot of great leadership reads this time around!

  • If You Don’t Treat Your Interns Right, You are Mean…and Stupid: This is a great post by¬†Nancy Lublin¬†that talks about something many full-time people share a common (and usually lousy) perspective on: interns. In my opinion, if you aren’t going to treat your interns well, you shouldn’t be hiring them. One key take away point from the article is ensuring that you treat your internship programs as something real and meaningful. Now, as a computer engineering graduate from the University of Waterloo and from being part of the leadership staff at Magnet Forensics, I’ve seen both sides of the story. Companies should treat their interns well, but interns should also realize companies are giving them the opportunity to be part of something great. It can be a win-win situation if both sides put in the time, effort, and dedication… but it can also be a lose-lose if approached poorly.
  • Does your company culture resemble jungle warfare?: Barry Salzberg¬†talks about office politics in this article. Key take away points? Be aware of the politics but don’t participate. Work together as a company toward your mission and embrace your company values. There’s no room for politics if you want your company to achieve greatness. Politics only interfere and hinder the business.
  • At Home This Weekend? Try This!: Presenting… The Weekend CEO Challenge from¬†Steve Tappin! I thought this article was a pretty cool perspective on how some top CEOs are spending their weeekends. Interested in doing any of these things over the weekend? Do you already do some of these things?
  • Resist the “Us vs. Them” Mindset: Daniel Goleman¬†shares a quote about embracing an “us” vs “them” mindset. Look for the common goals you share with others and embrace them together. Work together and stop viewing others as enemies. It’s hard to be successful if you’re always worrying about thwarting your enemies, so why not rally your friends and work as a team?
  • It’s Time to Change Your Outlook on Change: Change isn’t a problem, according to¬†Daniel Burrus. The problem is the fact that we sometimes fear change despite the fact that we’re built for it. In order to handle change well and be able to embrace it, we need to practice anticipating it. Stop leading blindly and acting surprised when things don’t go as planned… Start being proactive and paying attention to warning signs.
  • The Great Office Space Debate Rages On: Jennifer Merritt¬†talks about a topic that’s been going back and forth for some time now: office layouts. It used to be the norm for companies to have cubicles and offices on the peripherals of a floor. Now the open concept offices have gained tons of traction and companies are even going to extremes and not having fixed work placements. What’s your opinion on office layout?
  • Four Things to Ask Yourself Before Arguing: Rita King¬†addresses four really good things to ask yourself before you consider getting heated over what someone’s said or done. We’ve all been in a situation where someone’s done something to get us fired up, but is it really worth it? If you can manage it, try asking yourself the questions Rita discusses (are you listening? are you repeating patterns? do you understand the other person’s perspective? is there anything to be gained?) and perhaps you can cool yourself off before ruining your own day/week/month.
  • Change Your Habits with a Good Checklist: Habits aren’t easy to change.¬†John Ryan¬†writes about how you can use checklists to start enforcing good habits! Worth a shot at least, right? ūüôā
  • Culture Quartet: 4 Steps to Unify Your Company: In this article,¬†Dan Khabie¬†talks about the merger of two companies and how culture played a large role in the success of the merger. Your workplace culture is essential for creating the right atmosphere for people to be productive and work well together. Teams thrive when the culture in the workplace is positive and places value on the employees.
  • The Truth About Best Practices: Liz Ryan¬†discusses the how best practices can be like falling into a trap. Just because there is a best practice or certain metrics are a some sort of golden standard, it doesn’t mean you should blindly follow along. Does the process make sense for your company? Your team? Do the metrics make sense for your industry? Your market? At this current time? Focus on what matters and don’t get distracted.
  • Did You Make The Most of Your Mid-Year Review?: What makes a mid-year review useful?¬†Linda Descano¬†discusses four major points that include having an engaged conversation between both leader/manager and employee, constructive feedback for the employee to work on, and what goals are and how they can be accomplished. If you find reviews to be a time waster, is it because they’re not being conducted well? Are they a waste because nobody is engaged? Or are there other reasons that mid-year reviews feel like they aren’t useful?
  • Do You Find It Difficult to Claim Your Authority?: Judith Sherven, PhD¬†addresses some common reasons why people often don’t consider themselves authorities. It’s a shame too, because it can hold people back from their full potential. If you have great experiences, skills, or you’re knowledgeable in a particular area, why wouldn’t you consider yourself an authority?
  • Where Are You on the Leadership Continuum?: When people consider good leaders, they often describe common traits.¬†Joel Peterson¬†points out that these traits often have varying meanings depending on the person using them. I’d recommend going through his list because it’s pretty interesting to see two very opposing descriptions for the same trait. You might even notice that a trait you would use to describe a leader is actually commonly described by others in a very different way. Definitely interesting!
  • Making Stone Soup: How to Really Make Collaborative Innovation Work Where You Work: Jeff DeGraff¬†discusses some key points for having effective collaborative innovation. Setting high impact targets, recruiting domain experts, making multiple attempts, and learning from your experiences are all major points that DeGraff discusses. There’s also a playlist of videos discussing innovation, so there’s lots of content to absorb ūüôā

Hope you enjoyed! Remember to follow on popular social media outlets to get these updates through the week!

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+


API: Don’t Forget About The Non-Public API!

Image courtesy of FreeDigitalPhotos.net

Background

From an¬†object oriented programming perspective, an application programming interface (API) is often referred to as the way other developers can interact with the public members of your class(es) and interface(s). Of course, API can be used to describe how one interacts with a web service (or other types of services), but for this discussion I’m limiting the scope to that of interfaces and classes. Limiting the definition of API to public members (or the equivalent of C#’s “public” in other languages) is omitting one huge part of what it encompasses. The purpose of this post is to clarify, in my opinion, why I think forgetting about the non-public API can lead to bad framework and API designs.

API And The Audience

I’ve written before about what I think makes a good API, and I had some comments on Code Project on the same posting that lead me to this topic: the audience. There’s a lot to consider when you’re writing what many people would consider good, clean code. It’s impossible to please everyone because everyone has some sort of best practice, guideline, or convention that they follow because they believe it’s the best. So, I’m not going to tell you that some way is the best… I just want you to be conscious of your audience so that you can make better decisions.

Okay, okay… So what do I mean by audience? I’m going to generalize your audience (the consumers of your API) into two distinct categories. The first category is the group of developers who will be using references to things that implement your interfaces and your concrete classes. They’ll use the instances of the things you define. For example, let’s consider a something built-in to the .NET framework: the List<T> class. Your first group of API consumers are just going to use instances of this class exactly as provided by the framework. They’ll make new instances of them and pass them around to be used in functions, or make properties that return instances of List<T>, or declare variables of type List<T>, etc… They use it as is, as provided.

The second general group of API consumers are the ones who are going to be extending your interfaces and classes. A great example of this is the EventArgs class. This class is super basic; It doesn’t do anything! Anyone who wants to use the EventArgs class essentially has to make their own class that inherits from EventArgs. Another example of this is the Exception class. Again, this class is built for people to extend it with their own implementations. I suppose both of these examples are pretty primitive because the base classes don’t offer much functionality, but what if your class wanted to let child classes override the default behaviour? I’ll have some more concrete examples of this later on.

Intentions Of The Audience

With these two general types of consumers defined, it’s a bit easier to consider how people may want to use your API differently. The first class of consumer wants to able to easily call your methods that you’ve defined and easily create the objects/interfaces that are core to your API. This means that the input they need to provide should be extremely basic, so using things like built in interfaces, or other classes that you’ve defined that are easy to create. These consumers also want information-rich return values and classes. Why? Because it makes their life easy! If they only need to provide a little bit of information and they get a lot back, they’re able to do a lot more with the data that they have access to. They don’t need to (and they certainly don’t want to) call 10 different things in intricate ways to get a little bit of data back.

The second class of consumer takes the exact opposite perspective. Here’s why. In the first case where the first group of consumers want to pass in only minimal information to methods, the second class of consumer wants lots of information passed in. This class of consumer is required to do some job or return some data, so the more information they are provided the easier it is for them to perform their job. Similarly, they want the return values of methods to be as simplistic as possible. Why? It makes their job easier! If they are responsible for returning some incredibly complex class from a method defined in your interface, and the input to that method is only minimal information, this makes the job of the second class of consumer quite difficult.

The best way to remember these similarities and differences is that the flow of data is opposite depending on what type of API consumer you’re talking about. The first type of consumer wants to provide a little and get a lot, and the second type of consumer wants to get a lot and provide a little. Makes sense right? Everyone wants to do the easy thing.

The take-away here is that depending on who you think your main audience is going to be for your API, it will affect how you structure it. And this is exactly why forgetting about the non-public API can be a huge mistake. Forgetting this part of the API makes the whole thing difficult to extend because your base classes cannot as easily be built on top of. You actually make the lives of the second class of API consumers very difficult if you ignore their needs.

Example: WinForms

If you’ve done desktop application development in C#, you’ve likely used (or at least heard of) WinForms. Some people new to desktop application development might have actually started with Windows Presentation Foundation (WPF), but the same concepts will apply here. In my opinion WinForms is a great example of an API that has both public and non-public components that were designed with both audience types in mind. Let’s start with the first class of API consumers.

If you’ve dabbled in WinForms, you’re likely familiar with the Windows Form Designer offered in Visual Studio. If you are… then congrats! You’re the first class of API consumer that I’ve described. By using the built in classes like Buttons, TextBoxes and Labels, you’re using the out-of-the-box components offered in the framework and consuming the public API offered by these controls. You’ll be using things like the Text property offered on these controls and interacting with them via their events (i.e. hooking onto click events or text changed events). You’ll be using the public API. Nothin’ wrong with that!

//
// MyButton
//
this.MyButton.Location = new System.Drawing.Point(146, 84);
this.MyButton.Name = "MyButton";
this.MyButton.Size = new System.Drawing.Size(75, 23);
this.MyButton.TabIndex = 0;
this.MyButton.Text = "Click Me!";
this.MyButton.UseVisualStyleBackColor = true;
this.MyButton.Click += new System.EventHandler(this.MyButton_Click);

private void MyButton_Click(object sender, EventArgs e)
{
    // do stuff!
}

Now, the creators of WinForms weren’t dummies. They knew that they weren’t going to be able to offer you every possible control you’d ever need. They made the API in WinForms have great support for the non-public members of their base classes! So, what do I mean by that?

Let’s pretend we want to have our own fancy button class. Because our button is fancy, we always want to tell the user just how fancy it is when they click it. Now if the framework you were using had a poorly designed API, you might be forced to code a button from scratch. That would be pretty lame considering the complexity of the built-in controls offered to you already. For this example, you could surely just create one button and hook an event handler onto the click event (using the public API), but what if you wanted to re-use this everywhere throughout your user interface? You’d want your own FancyButton class that has this behaviour built-in so you can easily reuse it. No problem.

private class FancyButton : Button
{
    protected override void OnClick(EventArgs e)
    {
        base.OnClick(e);
        this.Text = "The fancy button was clicked.";
    }
}

The non-public API in WinForms gives you access to built-in behaviour of the base classes. You don’t need to hook onto events to get the job done, you can actually override the OnClick method and prevent the click event from even firing! The focus on the non-public API allows developers to extend the built-in classes without having to design their own from the ground up.

Summary

It takes a lot of practice and experience to be able to write a good API. There’s also plenty of different opinions on what constitutes a well-designed API. In my opinion, you need to give a lot of thought as to how your API will be used. Consider the two general types of API consumers I’ve defined: The consumers that use your API with the public parts of the interfaces and classes you’ve defined, and the consumers that want to extend your defined classes to provide their own related implementations. These two types of consumers will want very different things, and in order to please the second class of consumer, you absolutely cannot forget about the non-public API.

Some food for thought:

  • How can I best guess how developers will use my API?
  • I’m providing base classes with my framework and API. Can people easily extend them through inheritance? Will people want to extend them?
  • What would make my public API easier for other developers to use?
  • What would make my non-public API easier for other developers to build on to my base classes?

  • Nick Cosentino

    Nick Cosentino

    I work as a team lead of software engineering at Magnet Forensics (http://www.magnetforensics.com). I'm into powerlifting, bodybuilding, and blogging about leadership/development topics over at http://www.devleader.ca.

    Verified Services

    View Full Profile →

  • Copyright © 1996-2010 Dev Leader. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress