Tag: Analysis

How to Refocus: Getting Back in the Groove

How to Refocus: Getting Back in the Groove

Identifying when you need to refocus

It happens to everyone at some point to varying degrees, for various reasons, and at different times in our lives–but it’ll happen! You hit a period or a rut where you can’t keep your focus on continuing to be successful (and I’m over-generalizing that for a good reason).

Maybe this means you can’t focus at work to perform at an optimal level. Maybe you’re falling off the diet you’ve been working hard on. Maybe your training in the gym or for your sport is taking a hit because your head isn’t in the game. Maybe you find yourself unable to hit the books studying or completing your projects in school.

It can look different for everyone.

There are a bunch of different little warning signs that things aren’t quite on track and you need to refocus:

  • You’re losing interest in what you’re working on or have been working towards
  • You can’t seem to keep your mind on the goal(s) that you’ve set
  • You feel like you’re plateauing in your progress toward your goal(s)
  • You’re suddenly finding you’re not happy or not feeling fulfilled
  • You’re taking out stress on your co-workers, friends, or loved ones
  • You’re isolating yourself from friends and family
  • You find yourself overly concerned with things you can’t change (dwelling on the past or fearing a future event, like an exam)

But don’t freak out just yet… you need to see and acknowledge the signs before you can start to make any progress. Feeling pretty good about everything in your life? Then keep doin’ what you’re doin’! If any of those points seemed to resonate with you, then let’s continue on!

Don’t worry

If you’ve found that you’re in a bit of a rut, it’s important to not worry. You need to remind yourself that you were once on track and you’ll get back on track. You’ve already identified you need to refocus, so you have the power to get back on track.

Worrying about the fact you’ve identified you’re not in an ideal state of mind doesn’t help anything; in fact, it makes it worse.

“I can’t seem to find my focus at work… I’m going to be such a bad employee. I wonder if I can even get my work done now. My colleagues are going to notice… My manager will notice!”

“Training has really been kicking my butt… Why am I even doing this? I wonder if I should just give up. I haven’t seen any progress in my abilities in the past couple of weeks. I’m hopeless at this.”

“There’s a lot going on at school now and I can’t seem to keep up anymore. I’m going to fail this project that’s due next week because I can’t seem to get started on it. And my exams are coming up and I can’t seem to study. I’m going to fail this term.”

All of that kind of talk is negative and it’s not going to help you progress! So why are you continuing to focus on hampering your progress? Don’t do it. Instead, acknowledge you’re looking for a positive change, and then acknowledge that you’re in full control to start making that change.

And step one is to stop worrying and drop the negativity.

Analyze what’s getting you down

I get told that the engineer in me talks too much about analysis… but I think it’s a critical step! You need to understand the things that are getting you down. You’ve identified that you need to refocus because you’re not happy with your current behaviour or state of mind, but what are those things that are getting you down?

If you understand what’s getting you down you can start to take corrective actions. It’s got a (cue the fancy buzzword) synergistic effect with my previous point–Drop the negative thoughts and work on correcting them in parallel.

Let’s look at a couple of potential examples:

  • You’re unable to see any progress in your work, schooling, or training
    • How are you measuring progress right now?
      • Some things aren’t well suited for quantitative measurement
      • Try and identify a consistent mechanism for measuring progress
    • How often do you measure progress?
      • Some things don’t change very frequently so it’s hard to notice progress
      • Many things don’t progress in a totally linear fashion
    • Is it time to update your strategy for continuing success?
      • How long have you been doing the exact same thing expecting to get the same increase in results?
      • Have other environmental factors changed that suggest you should update what you’re doing?
    • Have you actually compared your current status to a previous point in time, or is it just how you feel?
      • Maybe it’s all in your head!
      • Try reflecting on where you were a month ago, 6 months ago, and a year ago.
  • You’re constantly comparing yourself to others
    • Do you actually know all the ins and outs of a person’s life?
      • Just because you observe certain things, it doesn’t mean they’re exactly as they seem
      • If you don’t have the full perspective and details on someone’s life, you’re guaranteed to be misunderstanding something
    • Can you change other people?
      • … Even if you could, you shouldn’t!
      • See the next major point 🙂
    • Are you comparing different subsets of your lives and expecting them to align a certain way?
      • Other people are not you and are living a different life
      • You can only truly compare yourself to your own self at various parts in your life
  • You’re dwelling on things you can’t change
    • Are you expecting to change something in the past that’s already happened?
      • Unless you have a time machine, you absolutely cannot change past events
      • Trying to understand past events can be helpful learning for the future
    • Are you dreading an event in the future that’s unavoidable?
      • If you can’t avoid it, then work at accepting it’s going to happen. (Things like exams or year-end reviews for work, for example)
      • Ask yourself why you’re dreading it. Try applying this example of analysis to THAT reason and dive deeper.
    • Are you focused on the thoughts and emotions of other people?
      • You can’t (and shouldn’t try to) control how other people think and feel
      • The best you can do is focus on yourself and live the values that you believe in
      • When it comes to thoughts and feelings, we all observe and interpret on our own
    • Have you considered whether this situation is temporary?
      • When you don’t know how long you’ll be out of control, it can make you feel helpless
      • Knowing there’s a point in time where there’s a change that can affect your situation can be a great help (i.e. money is tight for two weeks and you just need that next pay cheque to come through)

These are just a handful of examples, but hopefully you can see a pattern:

  1. Identify a particular thing that you know is getting you down.
  2. Ask yourself what effects it’s having and why you believe it’s having those effects on you.
  3. Dive deeper on each one of those by repeating these steps.

It’s nothing groundbreaking and I’m not claiming it will magically fix your problems… But analyzing things can lead to understanding, and understanding can lead to progress.

Remind yourself of your strengths

Everyone gets down on themselves at some point and this will cause you to lose focus on your goals. But I guarantee you if you stop and think about it, there’s a lot of great things that you got going on!

Don’t believe me? I challenge you to take a pen and something you can write on.

  • Write three things you’re proud of or that you’ve accomplished
  • Write three things about why your best friends like you
  • Write down the thing you love doing most or loved doing most before this point in time
  • Write down the thing you think you’re best at

Now step back for a second and think about the things you wrote.

  • It’s very likely the accomplishments you made or things you’re proud of required you to overcome something. Unless you got lucky or had some magic, odds are you used your strengths to achieve these things.
  • Your friends stay by your side because they admire you. They admire the qualities you have and see strength in you. You might not realize these strengths, but your friends perceive these about you.
  • If you love doing something, you’re probably pretty good at it, and if you’re not, odds are you’ll get good at it because you love to do it! Acknowledge and understand what you’re passionate about because it will tell you about your strengths.
  • Sometimes you’re good at things that you’re not totally passionate about. That’s cool too! What makes you good at this thing? Can you apply this to other areas in your life?

Set some goals

At this point you’ve:

  • Identified that you’re not content with your current state
  • Reminded yourself that you can make a change
  • Analyzed what’s getting you down so that you have a better understanding of some direction to take
  • Reflected on your own personal strengths

And now… It’s time to set some goals!

Goals you set should ideally align with SMART goals. Do yourself a favour and check that page out for a little bit more information so you can set yourself up for success. You want to make sure you’ve agreed your goal is achievable within a certain period of time and that you can measure progress in some way as you go. This is critical for a few reasons:

  • No time box? How will you know if you’re on track?
  • No way to measure? … Same problem!
  • Not realistic or achievable? You’re setting yourself up for failure.

It seems obvious when it’s laid out like that, but this will keep you from setting goals like “I’m going to do better at work”, “I’ll kick my training up a notch”, or “I’ll worry less about what’s going on in other peoples’ lives”. None of those goal statements indicate when you’ll be done by or how you’re going to measure progress.

Here’s a simple example:

In the next month, instead of missing on average three practices per week, I’ll reduce this to one. I’ll make sure that I have things put into my agenda ahead of time so I won’t schedule things over practice sessions, and if something critical comes up last minute, I can use the following week to compensate for it.

  • Specifically about not missing practices
  • Measured weekly by an average of missed practices
  • Achievable because it’s an improvement and not an expectation of perfection
  • Realistic and with the reward of getting to more practices
  • Time boxed to one month.

Start slow and set one or two SMART goals. As you build confidence that you’re progressing in your goals, try adding in another. You don’t want to overwhelm yourself!

Be brave enough to ask for help

If you’re reading this and you’re considering making changes then you’re already starting your path to progress. That’s AWESOME and you’re a strong person for being able to get started.

Sometimes things can get tough though. You might feel you’ve made progress over a few weeks or months and seemingly fall back to square one. You might feel like you’ve set SMART goals but you’re having trouble even getting started. Maybe you read this and still don’t even know how to get started.

There are a million reasons why getting started or continuing can be hard. Be brave though. Ask for help. I can guarantee you have some amazing friends and family that love you that want to see you be successful. There’s nothing to be ashamed of when asking for help! It’s a courageous thing to admit that you’d like assistance on your path for doing better, and people see that. You might feel embarrassed or ashamed, but other people see a brave person trying to move forward.

Summary

It’s a common thing for people to fall into a figurative rut in life. It happens to everyone at some point and it’s nothing to get down on yourself about. You’re not a bad human being if it happens to you, so don’t sweat it.

Analyzing your current situation and why you feel certain ways can help you gain an understanding of what’s going on. Focus on driving out the negativity and create actions to try making progress by leveraging your strengths.

In the end, remember that you control your life and you can make all the positive changes to it that you want to see. It takes time and hard work, but if you put in the effort, you’ll always get to where you want to be.

Now get out there and go kick some ass.


What Makes Good Code? – Should Every Class Have An Interface? Pt 2

Should Every Class Have an Interface?

This is part two in the sub-series of “Should Every Class Have an Interface?“, and part of the bigger “What Makes Good Code?” series.

Other Peoples’ Code

So in the last post, we made sure we could get an interface for every class we made. Okay, well that’s all fine and dandy (I say half sarcastically). But you and I are smart programmers, so we like to re-use other peoples’ code in our own projects. But wait just a second! It looks like Joe Shmoe didn’t use interfaces in his API that he created! We refuse to pollute our beautiful interface-rich code with his! What can we do about it?

Wrap it.

That’s right! If we add a little bit of code we can get all the benefits as the example we walked through originally. It’s not going to completely fix “the problem”, but I’ll touch on that after. So, we all remember our good friend encapsulation, right?

Let’s pretend that Joe Shmoe wrote some cool code that does string lookups from an Excel file. We want to use it in our code, but Joe didn’t use the IStringLookup interface (because… it’s in OUR code, not his) and he didn’t even use ANY interfaces. The constructor for his class looks like:


public ExcelParser(string pathToExcelFile);

On this class, there’s two methods. One method allows us to find the column index for a certain heading, and the other method allows us to get a cell’s value given a column and row index. The method calls looks like:


public int GetColumnIndex(string columnName);

public string GetCellValue(int columnIndex, int rowIndex);

We can wrap that class by creating a wrapper class that meets our interface, like so:


public sealed class ExcelStringLookup
{
  // ugh... we have to reference the class directly!
  private readonly ExcelParser _excelParser;

  // ugh... we have to reference the class directly!
  public ExcelStringLookup(ExcelParser excelParser)
  {
    _excelParser = excelParser;
  }

  public string GetString(string name)
  {
    var columnIndex = _excelParser.GetColumnIndex(name);
    // assumes all of our strings will be under a column header
    var cellValue = _excelParser.GetCellValue(columnIndex, 1);
    return cellValue;
  }
}

And now this will plug right into the rest of our code that we defined originally.

This doesn’t totally eliminate “the problem” though (the problem being that some class doesn’t have an interface (what this post is trying to answer)). There’s still a class we’re making use of that doesn’t have an interface, but it looks like we’ve reduced the exposure of that problem to JUST this class and the spot that would construct this class. Are we okay with that?

Thoughts So Far…

Let’s do a little recap on what we’ve seen so far:

  • Having interfaces for our classes is a nice way to introduce a layer of abstraction
  • Interfaces are just *one* tool to get layers of abstraction introduced
  • If you wanted to have interfaces for all of the classes in your code and some third party didn’t use interfaces, that code is likely not as common in your code base (especially if you wrap it like I mentioned above). This may not always be true in your code base, but it’s likely the case.
  • The amount of work to wrap things can vary greatly. Some things are straight forward to wrap, but you need to add many methods/properties. Sometimes it’s the inverse and you only have a few things to wrap but they’re not straight forward.
  • The number of classes you’d need to wrap to get to this state can vary greatly… Since even built-in System classes aren’t all backed with interfaces!
  • There’s certainly a trade off between the original work + maintenance to wrap a class in an interface versus the benefits it provides.

Is that last point blasphemy?! So there may actually be times we DON’T want to have an interface for a class?

Watch this space for part 3 where we start to look at a counter-example!

 


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.


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).


Continuous Improvement – One on One Tweaks

Continuous Improvement - One on One Tweaks

Continuous Improvement – Baby Steps!

Our development team at Magnet Forensics focuses a lot on continuous improvement. It’s one of the things baked into a retrospective often performed in agile software shops. It’s all about acknowledging that no system or process is going to be perfect and that as your landscape changes, a lot of other things will too.

The concept of continuous improvement isn’t limited to just the software we make or the processes we put in place for doing so. You can apply it to anything that’s repeated over time where you can measure positive and negative changes. I figured it was time to apply it to my leadership practices.

The One on One

I lead a team of software developers at Magnet, but I’m not the boss of any of them. They’re all equally my peers and we’re all working toward a common goal. One of my responsibilities is to meet with my team regularly to touch base with them. What are things they’ve been working on? What concerns do they have with the current state of things? What’s going well for them? What sort of goals are they setting?

The one on ones that we have setup are just another version of continuous improvement. It’s up to me to help empower the team to drive that continuous improvement, so I need to facilitate them wherever I can. Often this isn’t a case of “okay, I’ll do that for you” but a “yes, I encourage you to proceed with that” type of scenario. The next time we meet up, I check in to see if they were able to make headway with the goals they had set up and we try to change things up if they’ve hit roadblocks.

No Change, No Improvement

I had been taking the same approach to one-on-ones for a while. I decided it was time for a change. If it didn’t work, it’s okay… I could always try something else. I had a good baseline to measure from, so I felt comfortable trying something different.

One on ones often consisted of my team members handing me a sheet of past actions, concerns, and status of goals before we’d jump into a quick 20 minute meeting together. I’d go over the sheet with them and we’d add in any missing areas and solidify goals for next time. But I wanted a change here. How helpful can I be if I get this sheet as we go into the room together?

I started asking to get these sheets ahead of time and started paraphrasing the whole sheet into a few bullet points. A small and simple change. But what impact did this have?

Most one on ones went from maxing out 20 minutes to only taking around 10 minutes to cover the most important topics. Additionally, it felt like we could really deep dive on topics because I was prepared with some sort of background questions or information to help progress through roadblocks. Myself and my team member could blast through the important pieces of information and then at the end, if I’d check to make sure there’s nothing we’d missed going over. If I had accidentally omitted something, we’d have almost another 10 minutes to at least start discussing it.

Trade Off?

I have an engineering background, so for me it’s all about pros and cons. What was the trade-off for doing this?

The first thing is that initially it seemed like I was asking for the sheets super early. Maybe it still feels like I’m asking for them early. I try to get them by the weekend before the week where I start scheduling one on ones, so sometimes it feels like people had less than a month to fill them out. Is it a problem really? Maybe not. Maybe it just means there’s less stuff to try and cram into there. I think the benefit of being able to go into the meeting with more information on my end can make it more productive.

The second thing is that since I paraphrase the sheet, I might miss something that my team member wanted to go over. However, because the time is used so much more effectively, we’re often able to cover anything  that was missed with time to spare. I think there’s enough trust in the team for them to know that if I miss something that it’s not because I wanted to dodge a question or topic.

I think the positive changes this brought about have certainly outweighed the drawbacks. I think I’ll make this a permanent part of my one on one setup… Until continuous improvement suggests I should try something new!


Yield! Reconsidering APIs with Collections

Yield! Reconsidering APIs with Collections (Image by http://www.sxc.hu/)

Yield: A Little Background

The yield keyword in C# is pretty cool. Being used within an iterator, yield lets a function return an item as well as control of execution to the caller and upon next iteration resume where it left off. Neat, right? MSDN documentation lists these limitations surrounding the use of the yield keyword:

  • Unsafe blocks are not allowed.
  • Parameters to the method, operator, or accessor cannot be ref or out.
  • A yield return statement cannot be located anywhere inside a try-catch block. It can be located in a try block if the try block is followed by a finally block.
  • A yield break statement may be located in a try block or a catch block but not a finally block.

So what does this have to do with API specifications?

A whole lot really, especially if you’re dealing with collections. I personally haven’t been a big user of the yield keyword, but I’ve never really been forced to use it. After playing around with it for a bit, I saw a lot of potential. I’ve written before about what I think makes a good API. In my article, I was making a point to discuss two perspectives:

  • Who needs to implement your interface. You want it to be easy for them to implement.
  • Who needs to call your interface. You want it to be easy for them to use.

In my opinion, the IEnumerable<T> interface was a tricky thing to work with as a return value. You can essentially only iterate an IEnumerable, and at the time of calling a function, maybe that’s not what you want to do. The flip side is that for the person implementing the interface, IEnumerable<T> is a really easy interface to satisfy. However, the yield keyword has opened up some new doors.

In this article, I’d like to go over a couple of different approaches for an API and then explain why the yield keyword might be something you consider next time around. Disclaimer: I’m not claiming anything I’m about to present is the only way or the best way–I’m just sharing some of my own findings and perspective.

Interface For Returning Collections

The first type of API I’d like to look at is for returning collections. Based on my own API guidelines, I’d ideally choose an interface or class to return that provides a lot of information to the caller that is also easy to create for the implementer of my interface. The List<T> class is a great choice:

  • It’s easy to construct
  • It’s built-in to the .NET framework
  • It provides many handy functions (All of the IList<T> functionality as well as things like AddRange(), or functions that support delegates)

My next choice might be to have a return type of IList<T>, which would provide a little less ease of use to the caller, but make it even easier for the implementer of the interface. They could return arrays of type T, since an array implements the IList<T> interface, or their own custom list implementation that doesn’t inherit from the List<T> class. The differences between using IList<T> and List<T> are arguable pretty small.

A third alternative, which I would have avoided in the past, is to return an IEnumerable<T>. My opinion used to be that this made the life of the interface implementer a bit easier compared to returning an IList<T>, but complicated the life of the caller for a couple of reasons:

  • The caller would have to use the results of the function in a foreach loop.
  • The caller would have to add the items to their own collection to be able to do much more with the items.

My naive implementations of being forced to return an IEnumerable<T> were… well… crap. I would have constructed a collection within the function, fill it up, and then return it as an IEnumerable<T>. Then as the caller of my function, I’d have to re-enumerate the results (or add it to another collection):

public static IEnumerable<T> GetItems()
{
  var collection = new List<T>();
  // add all the items to a collection
  return collection;
}

private static void Main()
{
  var myCollection = new List<T>();
  myCollection.AddRange(GetItems());
  // use myCollection...

  // or.....
  foreach (var item in GetItems())
  {
    // use the items
  }
}

Seems like overkill to me with that implementation. However, we’ll examine how using yield can truly transform this into something… better. So to reiterate, a few potential implementations for an API involving collections might be:

  • Return a List<T> class
  • Return an IList<T> (or even an ICollection<T>) interface
  • Return an IEnumerable<T> interface

Constantly Creating Collections

My design decisions, in the past, were really driven by two guidelines:

  • Make it easier for the person implementing/extending the API
  • Make it easy for the person consuming the API

As I quickly illustrated in the first section, this meant that I would have a method where I would create a collection, fill it with items, and then return it. I could generally pick any concrete collection class and return it since I would usually pick a simple collection as the return type. Easy.

One thing that might be noticeable with this approach is that it looks pretty inefficient to keep creating new collections, fill them, and then return them. I’ll illustrate with a simple example. We’ll create a class that has a method on it called GetItems(). As per my reasoning presented earlier, we’ll have this method return a List<T> instance, and to make this example easier to work with, we’ll pass in an IEnumerable<T> instance. For what it’s worth, the input to this function is really just for demonstration purposes here–We’re really focusing on how we’re creating our return value.

public class CreateNewListApi<T>
{
  public List<T> GetItems(IEnumerable<T> input)
  {
    var newCollection = new List<T>();

    foreach (var item in input)
    {
      newCollection.Add(item);
    }

    return newCollection;
  }
}

And now that we have our simple class we can mock up a little test for performance… Just how inefficient is creating new lists every time?

internal class Program
{
  private static void Main(string[] args)
  {
    const int NUM_ITEMS = 100000000;
    var inputItems = new int[NUM_ITEMS];

    Console.WriteLine("API Creating New Collections");
    var api = new CreateNewListApi<int>();

    var watch = Stopwatch.StartNew();
    var results = api.GetItems(inputItems);

    foreach (var item in results)
    {
    }

    Console.WriteLine(watch.Elapsed);
    Console.WriteLine(Process.GetCurrentProcess().PrivateMemorySize64);
    Console.ReadLine();
  }
}

When I run this on my machine, I get an average of about 1.73 seconds. The memory printout I get when running is 1615908864 bytes. So is that slow? Is that a lot of memory usage? I think it’s pretty hard to say conclusively without being able to compare it against anything. So let’s keep this number in mind as we continue to investigate the alternatives.

Side Note: At this point, some readers may be saying “Well, if the input to our function was also a list (or if whatever our function has to work with was otherwise equivalent to our return value) then we wouldn’t have to go populate a new collection every time… We can just return the underlying collection”! And I would say you are absolutely correct. If your function has access to an instance of the same type as the return type, then you could always just return that instance. But what implications does this have? You’re now giving people access to your underlying internals, and they can go modify them as they please. So, if you need to control access to items being added or removed, then it might not make sense for you to expose your internal collections like this.

Yield to Incoming API Alternatives

We’ve seen how my past implementations may have looked, so how might we tweak this? If we tweak our API a bit, we can make our method return an IEnumerable<T> instead. Let’s see what that might look like:

public class YieldingApi<T>
{
  public IEnumerable<T> GetItems(IEnumerable<T> input)
  {
    foreach (var item in input)
    {
      yield return item;
    }
  }
}

So in this API implementation, all we’ll be doing is iterating over some type of collection and then yielding each result. If we run it through the same type of test as out previous API implementation, what kind of results do we end up with?

internal class Program
{
  private static void Main(string[] args)
  {
    const int NUM_ITEMS = 100000000;
    var inputItems = new int[NUM_ITEMS];

    Console.WriteLine("API Yielding");
    var api = new YieldingApi<int>();

    var watch = Stopwatch.StartNew();
    var results = api.GetItems(inputItems);

    foreach (var item in results)
    {
    }

    Console.WriteLine(watch.Elapsed);
    Console.WriteLine(Process.GetCurrentProcess().PrivateMemorySize64);
    Console.ReadLine();
  }
}

When I run this on my machine, I get an average of about 2.80 seconds. The memory printout I get when running is 449409024 bytes. How does this relate back to our first implementation? Well, it’s certainly slower. It takes about 1.62x as long to enumerate using the yield implementation as it did with the first API we created. However, yield also uses less than 1/3 (about 27.8%, actually) of the memory footprint when compared to the first implementation. Pretty cool results!

Site Note: So yield was a bit slower according to our results, but what happens if print the elapsed time before we run that foreach loop? Well, on my machine it averages at about one millisecond. Now that’s fast, right?! The cool thing about using yield with the IEnumerable<T> interface is that the work is deferred. That is, not until the program goes to actually run the enumeration do we get our performance hit. Try it out! Try moving the time printout from after the foreach loop to before the foreach loop. Try sticking breakpoints in on the line that yields. You’ll see what I mean.

Summary

In this article, I’ve explored two different ways of implementing an API (specifically focusing on the return value). We saw a brief performance analysis between the two and I highlighted some differences in both approaches. Let’s recap though:

  • Approach 1: Returning a List<T> and creating the collection ahead of time
    • Appeared to be overall a bit faster then yielding.
    • Consumed much more memory than yielding.
    • Callers can use the results immediately for enumeration, checking count, or as a collection to add more things to
    • The return type of List<T> is a bit more restrictive than an IEnumerable<T> like in the second API implementation
  • Approach 2: Return type of IEnumerable<T> and yielding results
    • Appeared to be overall a bit slower than the List<T> implementation
    • Lazy. We don’t actually execute any enumeration code until the caller actually enumerates
    • Consumed significantly less memory than the first approach using List<T>
    • Callers can enumerate the results immediately, but they need to add the results to a collection class to do much more than enumerate

So next time you’re designing an API for your interfaces and classes, try keeping these things in mind!

EDIT (December 30th, 2013):
As per some comments on Google+ by Dan Nemec, I figured I’d add a bit more here in the summary. IEnumerable<T> on it’s own is certainly not useless, especially if you’re leveraging LINQ or extension methods. My main beef in the past was that the consumer of an API with a IEnumerable<T> return value can only iterate over the results… And that’s just because that’s all that IEnumerable<T> lets you do. Dan made a great point though–If you are leveraging things like extension methods, or LINQ (which introduces tons of handy extension methods for working with IEnumerable<T>) then you get all of that functionality tacked on to IEnumerable<T>.

So if you’re not fortunate enough to be working with LINQ or extension methods (i.e. working with legacy code in old .NET framework versions… and yes I am familiar with the attribute you can add in to allow extension methods provided you have a compiler version high enough to support it), then IEnumerable<T> sometimes just plain sucks. I’d wager the majority of C# developers aren’t in this boat though, so I’d like to thank Dan again for his comments.


  • 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