• May
    13

    TDD Study Group: Week 1

    by Nathan Sickler

    As you’ve no doubt heard from another blog post/email/coworker if your an employee here at SEP, we’re beginning some TDD Study Groups here at SEP. One of the goals of the TDD Study Groups is to have some visible output from each of the groups, so we can spread some information further than just those in our meetings. As a result, you’ll be seeing more posts like this one in the weeks to come. I’m playing role of recorder for our group, so I’ll be doing my best to separate the results of the group from my own opinions (by making separate posts with different titles).

    I know some of the other team members are planning to make some public posts about their experiences/opinions on the material, so expect some updates with links to their posts as they become available.

    Background

    As a bit of background info, we’ve split up all those interested into groups based on technology known, in our case ASP.NET MVC. Since we’re all on the same billable project team, our discussion tends, not only towards how we can improve our own development skills and how TDD is/isn’t the way to do this, but also towards the implications this has towards our project as a whole. With that in mind, let’s get down to what we did and felt about our first of six weeks of TDD Study groups.

    Homework

    Our “homework” for week one was to do some readings related to TDD/unit testing – listed below, and we decided coming to the meeting with our own personal goals/desires from TDD would help us get more out of our study groups, as well as discovering what’s stopping us from using TDD today.

    Our Goals

    • Apply TDD to Legacy Environment
    • General TDD Crash Course
    • New Way of Thinking/Getting Feedback

    What’s Stopping You from Using TDD Today?

    • Slow Build Time
    • Slow Test Spin Up Time

    Readings

    Reading Discussion

    When is doing the dumbest thing possible the right thing?

    Some members suggested that things like making a method return a constant value really doesn’t provide any value, since the result is clearly wrong for any input other than this one. However, as one group member suggested, in cases where the desired equation is unknown, having a starting value, and working outwards handling more and more cases – refactoring a number into an equation. Making the tests drive to a proper implementation each step of the way.

    How Important is it to see the test fail first?

    Well, if you’re writing a test that you expect to fail, and it passes – you’re probably writing a bad test. Either that, or you’ve taken your previous implementation beyond the requirements of the previous test.

    Programming Practice

    The second hour of our session was spent practicing TDD from developed stories – in our case, a stockroom application that allows multiple locations, bins and a separate collection of items per bin. The last few minutes were devoted to discussing what we learned in the exercises for the day.

    Note that since we didn’t complete the selected stories for the day, we didn’t take a lot of time to discuss lessons learned.

    Lessons Learned

    Pair Programming vs. Side-by-Side Programming

    One of the key concepts that comes with TDD is the idea of Pair Programming. In our example, we found that the discussion on the abstractions being implemented were the most valuable, though we imagined that more of a side-by-side programming approach where we discussed only the parts we felt most warranted discussion would be more valuable – allowing the ‘navigating’ developer to provide a second pair of eyes when the ‘driver’ really does need some input.

    (Rhyming) Quote of the Week

    Pairing is a tool not a rule. – RMN

    Posted in Engineering, TDD | No Comments »

  • Mar
    15

    Unwinding

    by Nathan Sickler

    Though this blog has focused on a means to improve one's professional success, there are many other means by which life can be measured, and although I don't feel my job defines who I am, I accept the fact that I will spend a significant portion of my life at my job. Even assuming I spend half of my waking hours on the job, there is another half to my life - one focused more on my own ejoyment and well-being. Don't get me wrong - I love my job, but we all have those times when we just need to unwind, cut loose and enjoy the moment.

    Not only is this a natural need for the mind/body; it's a good thing that will make you a more well-rounded person, and just as I've endeavored to spread my skills and make myself more of a generalizing specialist, I too endeavor to be a good husband, brother, friend and person with more depth than a professional life. If any of this sounds familiar, I'll come right out and admit it - I've stolen the idea taken the inspiration for this post from this podcast from This Developer's Life. If your ears have a spare 50 minutes, I highly recommend listening to this podcast (and all the others) and getting the information with one less man-in-the-middle.

    Striking a Balance

    My spare time is filled with many, many things. Friends, family, games, pets, side projects, you name it. Still I like to take time out of every day to sit back and relax - catch my breath and let the world move around me. Not only do I feel more productive afterwards, it helps me sustain my day to day momentum.

    Maybe for you this means that you take a slightly longer lunch break and play some cards. Break out the headphones and read a few blog posts in the middle of the day, even at the expense of working a little later. No matter how you do it, if you find that you enjoy your job, odds are pretty good you've learned to relax and combine some of your work and play.

    Measuring Success

    You know how after a long week you wake up and are relieved it's Friday. Well, I keep score by not realizing it's Friday. If in an average week, the weekend comes around and I'm none the wiser, I've done a good job of taking a step back and relaxing throughout the week (assuming I've put in 40 hours of work).

    If I find myself wishing for the weekend, I try to take a step back and find out why. Is there something happening that I'm looking forward to, or something I'm dreading that's happened earlier? Looking at these issues is important for improving your overall happiness.

    Reflecting on the week, the day, the month or the year will allow you to make some realizations. Maybe you'll find that on days when you're struggling with something new, you tend to be a little bit happier. Maybe on days when you have to touch that one part of the code, or deal with that one thing in particular (you know the one) you have a worse day than usual.

    One thing, we as a team, have started doing at work is using this tool as described by it's creator. It's simple to use, one click and done, and I've found thinking about it to be detrimental. Being in a bad mood can be for any reason - even those outside of work, and so interpreting the results should take that into account. If I've taken longer than a second to click one of the links, something's wrong... Once you're redirected, ask yourself why you clicked the button you did. You'll find this to be an effective means of finding what you do/don't like about your job/life.

    Act on It

    Just do it. I can't tell you what to do, so don't expect me to, but taking steps to mitigate the things that make you have bad days will make you a happier and more productive person. So will taking some time out of your work day to do something you enjoy. You'll be glad you did, and you might find your work improving as a result.

    Posted in Engineering, Habits, Happiness, Self Improvement | No Comments »

  • Nov
    15

    Being Selfish

    by Nathan Sickler

    Dear Reader,

    I must confess a deep dark secret of mine. This blog… it’s not about you. Don’t get me wrong, I appreciate someone out there reading what I write – it keeps me honest and motivated to continue writing, but I have my own selfish reasons for posting to this blog and setting a goal to start writing every day – the most obvious of which is to improve my own ability to communicate. Of course, communication is two-way, and I’d like to think that someone out there might learn something from my musings, but I’d like to be clear about my motivations for doing this. I want to get better at writing, and I want to become as prolific as some of you. The best way I could imagine to do this – to read and write about my craft each and every day, to keep up to date on the newest technologies and innovations and to keep working hard to accomplish those goals because I know well that none of you are sitting still.

    As a young developer, I am very much playing catch-up. I’m actively trying to gain mastery in a variety of areas to improve myself and provide more value to the company. Though I feel I do more harm than good for the projects in which I participate, still I stand on the shoulders of giants. I build on what the architects before me have created, pulling as much knowledge as I can from the existing system and from the act of completing tasks in the code base. I use my own selfish motivations to do some good and continue learning all the while, and every task I complete I am able to contribute even further.

    Everyone is motivated by how things will affect them. I approach each problem with my own preconceptions and desires for an outcome; I’d love to believe that these preconceptions and desires always match those of my company and my users, though I’m not so naive as to believe it. I know that any number of compromises are made along the way before it really reaches my plate as a developer, and it’s my job to resolve what I’m given in a way that is acceptable to all parties.

    Being aware of the differences between the interests of your client and your company will make you a better developer. Though it won’t mean that the code you write will be more elegant, your ability to deliver what the client needs (note I didn’t say ‘wants’) should be vastly improved. Knowing what to build, is often a more challenging task than actually building it. It stands to reason that the more involved one gets with the users, the more they can understand their needs. Using the system you build is a good first step (also known as dogfooding) to truly understanding your users and bridging the gap between their wants/needs and your wants/needs.

    So despite my selfish desires for this blog, hopefully this content will be useful to someone out there. And even if no one reads this, I’m more than happy to continue creating and making posts, if only due to the belief that my continued writing will make me better. I like to think that I’ve turned this selfish means of communication into something that provides some value. Learning to do the same for all your goals might earn you a support group of your own, or better yet some fans. Just keep turning your actions into daily wins and it’s hard to go wrong.

    So with that, I wish you the best of luck in finding the causes for your own motivations and turning those desires into little (or big) wins.

    Sincerely,

    Nathan L. Sickler
    Software Engineer

    Posted in Engineering, Self Improvement | No Comments »

  • Nov
    9

    “Weapon of Choice” or Belt of Tools?

    by Nathan Sickler

    The title of the SEP Blog Battle for this week is “Weapon of Choice”, and I thought I’d provide what insights I have on the topic as it relates to Programming Langauges.

    Origins for this Post

    In an effort to more effectively convey my thoughts on the matter, I thought I would provide a precursor – a recommended read which may well serve as a better means to convey my thoughts. This essay on generalizing specialists, which I originally discovered via this post, has been a model for my technical skill development in my time out of school.

    Apprentice’s Crutch

    As an Apprentice Software Engineer I have my own weapon of choice to solve problems in the realm of Software development (C#), though I am aware of how this limits me. As a result of this limitation, I’m actively pursuing means that will improve my prowess in other languages (in fact, I have a running list of technologies posted at my desk to help motivate me to do so, but that’s another post). Beyond the languages that I use on as part of my work, I’m taking opportunities to learn languages outside of that realm, and though I’m focusing on other languages and technologies we utilize inside the company for other projects, that is mostly because these languages are therefore potentially more useful to my current career as a software engineer.

    As a beginner – I rely on my (limited though it may be) expertise in my first real language to contribute as I grow further knowledge in a wider variety of languages. Though I believe I’ve exceeded the point at which I used my “hammer” (square peg -> round hole) of C# to force work items into the code base, I would still be approaching all problems this way, if I had never taken the time to expand my horizons beyond that first language and would therefore be a much less valuable asset to my company.

    Would I more quickly be able to master the language if I focused on utilizing it? Yes, but the learning curve is steep at this point, and I would be unable to take some of our user interface tasks, due to a lack of knowledge in Javascript. I would also be unable to do some of our more data intensive tasks, due to a lack of knowledge in SQL. In doing some generalizing after gaining some depth in my first language, I am able to do some of our most complicated tasks in one language, and at least some of the simplest in the others we use. If I had focused on a single language, I would potentially be able to do all of our complicated tasks, but none of our others, and any software developer can tell you that the times when a true expert are needed throughout the course of a product life-cycle are extremely rare at best.

    Master’s Arm

    That said, having an expert available to spend some time is an extremely valuable asset – one worth seeking out and spreading around (so long as they aren’t spread too thin). The master utilizes this language as an extension of himself. He/She wields this language as a powerful tool, laying the framework upon which can be built. A master is sought for his expertise and instead of utilizing a hammer to force the problem into his known domain, the code created by the master adds to the net value of the project. Of course, a master has many tools in his belt, some more specialized than others, but each has its purpose. Just as when driving a nail, you wouldn’t reach for a screwdriver, the master knows which tool to use for the job at hand.

    In Clean Code, you can find the following insight. “You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.” Almost everything created by the master falls into that second category, and even if he/she is more of a specialist (which may or may not be the case), with this expertise the project couldn’t be in better hands.

    TL;DR

    As a developer, when you write your first computer program you’re using the least specialized tool known to man. Let’s say its a sledgehammer. As you get better and better, you unlock newer and more precise tools. So while the first program you created was like building a house with a sledgehammer; you slowly discover as time goes on that a hammer is more effective at driving nails. Eventually you’ll learn that you can’t build a house with nails alone, and your tool belt will grow to accommodate more and more tools – thus allowing you to undertake more and more complicated tasks. The more you write the better you’ll become.

    At least, that’s how I think about it. I’ve noticed my techniques becoming more and more refined as I’ve grown as a software developer. All the while, I’ve tried to continually expand my horizons. As I spend my time at work on the same project, I continue to gain depth in those languages and techniques I’m using as part of my job, and while that depth isn’t necessarily a bad thing, I feel that each bit of increased depth allows for more breadth and vice versa, allowing me to be a more well-rounded developer. So while I still have my weapon of choice (and I no longer believe it to be a crutch), I am far from being an expert sought for his expertise. As a result, I need to gain other skills outside of my primary language to account for my lack of great technical skill to keep myself relevant and valuable as a developer.

    Posted in Learning, Self Improvement, SEP Blog Battle | No Comments »

  • Nov
    5

    Being Present

    by Nathan Sickler

    As with any thought intensive job, there is a need for a certain level of intelligence place on the employee. However, in most of these cases, another attribute can be even more valuable than shear intelligence… being present. Of course, I don’t mean just showing up for work on time; I mean an employee who is able to focus on the task at hand and not fall into auto-pilot on the “boring” tasks. As one actively trying to improve his work and dabbler in the methods of Zen meditation, I found this post on being present to be a great source of information and motivation. For the purposes of this blog, I’ll attempt to expand on the lessons in the linked article, and provide my own insights on making the transition from mindless drone to attentive superstar.

    Getting Started

    As is true in many new transitions, getting started is half the battle. There are some smaller steps to getting started which will ease the transition, and provide their own individual benefits as well.

    • Meditate before starting work. Taking some time out to clear your mind or explore yourself can be an extremely useful means to start any action. And since being present is a state of mind, gaining a fuller control over one’s thoughts is only way to do so.
    • Eliminate Distractions to a reasonable extent. Put in headphones at your desk (even if you don’t want to listen to anything) and your coworkers will likely assume you’d like to be left alone. Don’t outright ignore people – you won’t make any friends like that, but make it known that you’d like to be left alone from time to time.
    • Take breaks when appropriate. From time to time a task comes along that for one reason or another is difficult to implement. Maybe the code you’re trying to enhance is buggy, or the domain logic is rather complex, though doing everything in one sitting is a great indicator of being focused, if you find yourself getting drained or slowing down, take five. Go fill up your water bottle, take some time to chat with a coworker, or send that email you’ve been meaning to write. I find this little breaks give my mind a chance to ontinue processing and make more sense of a situation. Of course I tend to take these breaks as the code dictates – following individual logic chains to their conclusion before halting work.
    • Be patient and persistent – none of this will happen overnight. Set reminders for yourself – for example, I’ve created some wrappers for my common git commands that write entries to an Engineering Journal. So every time I checkout a branch, it writes a timestamp with the branch name to the file (for better time tracking), and outputs a specified set of text to my console. This serves as a wonderful reminder to focus on the moment. Presently, it takes the last quotation from the originally linked article – “I never think of the future. It comes soon enough.”

    Keeping it Going

    Once you’ve gotten started, it should be relatively easy to continue along at a brisk pace. Keep your reminders active, and remove them only once you are certain you are able to maintain momentum.

    Hopefully, these tips will enable you to be more productive and more in the moment in your daily activities and your job. I know that by doing the above I’ve noticed myself not taking less time to accomplish a task, but producing a higher quality product as well. Of course, these tips will only be most effective if you truly are passionate about the job at hand, or else you may find your mind wandering to escape.

    Are there any other helpful hints/tips you’ve discovered which help you be more productive at work or in other activities? If so, please let me know in the comments.

    Posted in Engineering, Focus, Habits, Meditation, Self Improvement | No Comments »

  • Oct
    30

    Engineering Over/Under: Finding Balance

    by Nathan Sickler

    The Blog Battle title for this week is “Engineering Over/Under”, and I thought I’d simply share my own experiences/inadequacies with this problem. As a young engineer (I am 23 and graduated roughly a year and a half ago), I have struggled much more with under-engineering, rather than over-engineering, but feel like I have some insights to share on both.

    Under-Engineering…

    is the tendency to over-simplify an issue/problem and introduce code that is inflexible, hard to read and/or hard to test. In my first few months on the job out of college, I undoubtedly introduced some of this code, and so did all of us. That’s one of the reasons why we have code review policies which require the code be viewed by another. I remember my early code review comments, numbering in length between 20-30 (well-deserved) suggestions and analyzing every one of them for where I went wrong. If it were not for these suggestions and my desire to learn from them, I would be months behind where I am today.

    What to do?

    First, learn from your mistakes. Find the patterns in your code reviews you receive and try to reduce the number of comments like it you receive. I got a lot of ‘Unit test this case’ until I started reviewing my own code and writing unit tests for every path I could find. Do this for all of your common comments, and ask questions on those comments you don’t understand. Taking this kind of initiative not only allows you to get better at your craft, but shows your team that you care about improving yourself and the quality of the product.

    Next, get to know your client/users. The better you can anticipate how they’ll use the software, the better you can find the right fit for the work you about to do. If you know the users tend to ask for a filterable data export, spend a bit of extra time making your search query reusable for the export, and you won’t have to double that amount of work. Just be careful not to over-engineer…

    Over-Engineering…

    is the tendency to over-think a problem and introduce code that is more complicated than necessary, resulting in putting too much time and effort into a feature than necessary. Wikipedia will gladly redirect you to an article on value engineering, which, to summarize, is the maximization of the ratio of function to cost. The less money that’s spent providing a valuable product to the users – the more money the company makes. The more money the company makes, the more employees they can hire, the more products they can undertake, the more profitable everyone becomes.

    Over-engineering, then, leads to more complicated code to maintain and more upfront money spent – providing no additional value. We could provide only features as they are requested, which would be best for the bottom line at the moment, or, we can spend a little bit of money now and save some time later.

    What to do?

    Sit down and ask yourself what the customer really needs, and if you can’t answer in a single sentence, then I can’t give you an answer here. Sometimes it’s best to hold off until they ask or are willing to pay, and others it’s best to anticipate their needs. In the end, it’s a judgement call. If you aren’t sure about this decision, ask your manager – that’s why they’re there.

    Of course, there’s some gray area here. I speak from the perspective of an engineer providing a service, so as a disclaimer, not everything I’ve stated may be best for you, your company or your household pets.

    Posted in Engineering, SEP Blog Battle | 3 Comments »

  • Oct
    27

    Embracing Change: Or How I Learned to Stop Worrying and Chuck My Daily Plans

    by Nathan Sickler

    First, some background. I’m working primarily on a time and materials project, focused on handling whatever problems may crop up that are currently high priority to our client contacts – either for the introduction of new features, fire-fighting or bug squashing. From time to time, something big enough will spontaneously combust, and I’ll be forced to drop everything I’m working on and run over and fight the fire that’s appeared.

    Though this didn’t (and doesn’t) happen often, when it did happen, it would disrupt the mental plan I’d formulated for the day. So instead of going from A to B to C, now I was working on Fire D, and since I didn’t meet my expectations for the day, I felt unproductive. I used to get upset that I had to put my work on hold and work on something else. And just in case the bolds didn’t give it away, I’ve come to realize exactly how selfish and stupid I was to think that way.

    It isn’t my time; for every moment I was working on my previous task, I was using the client’s time. I realized that my attitude was completely at odds with what I loved most about the project I was on – providing value and a service in the most direct means possible.

    Over time I’ve gotten better and better about shifting from one task to another, and, though I doubt that I’ll ever be happy to receive one of these calls (due to the fact that this usually means something is broken, and it is still disruptive to be torn from one task to another too often), I’ve learned to take these switches in stride – knowing that what I’m about to do is going to save the users from some pain they’ve been feeling.

    Lately, I’ve made a conscious effort to not formulate this kind of ad-hoc plan because the project priorities are constantly shifting from one side of the system to the other, and though this used to distract me, I’ve since learned that though the project may be being pulled in different directions, I don’t need to be pulled with it. No matter what I start to work on, I’ll be doing something of value for the users and the client.

    Every feature that gets implemented and bug that gets squashed helps to provide value and ease pain. Every fire that gets put out in a timely manner is one less affected user, or one more piece of data that gets entered into the system correctly. So I’ve given up planning my work item priorities, and when I complete a work item, I do a quick triage (value over effort) of the issues at the top of the priorities queue, and act from there. And if at the end of the day, I’ve done more good for the client than I’ve eaten in budget, then that was a productive day.

    Posted in Embracing Change, Scheduling | No Comments »

  • Oct
    24

    Developing Habits: Visualizing Daily Work

    by Nathan Sickler

    In a blog battle post earlier this week, I linked to a fairly old Lifehacker post on Seinfeld’s Productivity Secret - a simple means to visualize/motivate daily action on a specific type. Using a calendar, or a grid (template here) you can track the number of days you’ve completed your goal and, more importantly, the number of days in a row you’ve completed them.

    Here’s how I’m using it: At my desk I have these two grids labeled. I’ve marked my start date and end date – assuming a full year using the calendar, and drawn a line to separate the previous and current year. For every day I do meet my goal, I put an ‘X’ in the current date box in the grid, and repeat daily. For my own motivation, I’ll count up the current progress of my chain – how many days I’ve gone since the last time I broke the commitment when I come into the office in the morning. There are some online implementations of this system, but I found them to be too far out of sight and thus for me to remember to check them, let alone accomplish my goal.

    I find this method simple and effective. Every day I count the number of X’s I’ve accumulated on each grid, perform the task I’ve decided to track and put an X in if I’ve cleared my queue, or written something for this blog. The goal is to go as long as possible without breaking my chain of X’s for each task. That’s it.

    It’s easy to visualize/track, an extremely simple process and keeping it up and on display is another little motivator to keep the chain of X’s going. I’m not concerned with the length of time that I write each day, or the level of my work while tracking this process – those things will come naturally. Instead, my immediate goal is to get into a rhythm – to clear my queue at the beginning of the day and to plant the thought in my head that I need an idea to write about – or just continue where I left off the day before.

    Even if I don’t complete a post each day or decide that what I’ve written so far is no good and toss the whole thing, that’s okay because I know that I’ll write today, and what I don’t get done I’ll work on the next day. I’m not trying to set a record for the number of blog posts in a year, my goal is to improve and to accomplish something I’m passionate about.

    So if there’s something simple you care about enough to want to do everyday, start your own chain, put it up in your cube and proudly mark your X for each day you’ve earned it. Over time, you’ll improve and your schedule will shift to reflect the practice and you won’t need the calendar anymore. Just be persistent, and you’ll get better at writing, constantly be up to date on the blogs you care about, or meet whatever other goal you hope to reach. Best of luck, and don’t break your chain.

    Posted in Habits, Self Improvement, Visualizing Work | No Comments »

  • Oct
    22

    “Get Better” – Fail

    by Nathan Sickler

    In the spirit of Getting Better – I’ll inaugurate this blog with the SEP Blog Battle. The title for this week is one near to my heart – “Get Better”, so I’ll jump right into it.

    Though not exactly a new idea, I thought I would express my love for failure. I don’t mean the kind of failure where you’ve introduced a breaking bug into a piece of client software and your phone is ringing off the hook with angry, angry users. I’m talking about setting out with the intention of trying something new or pushing what you think you can do. There’s little that gets me more motivated than trying out something on Programming Praxis or another such site and having my solution not work.

    Why? I get to learn something new. I get to tear my best laid plans apart to find out what’s wrong – effectively breaking my toys. I get to try and try again until I get the satisfaction of victory, and then I get to look at other solutions and dig through to try to find an even better way to do things, and there’s little more humbling and enlightening than discovering that your solution that you fought tooth and nail to reach is terrible compared to what someone else came up with in an afternoon.

    Just be persistent and open. Accept your defeats and you’ll learn from them. If we all gave up the first time we got a build error, a unit test broke or a run-time error occured, computers, the light bulb, you name it wouldn’t exist. Persistence is the key in getting better, and so, if you have problems getting started use some means to visualize your progress. For complicated tasks, roll your own Kanban board. For simpler tasks, like practice start up a Seinfeldian Chain (a little known wonderful motivation technique), and try not to break it.

    So go ahead and be the worst; build some breakable toys in a technology you’ve never used before. Solve problems no one has asked you to solve; write your first blog post. It doesn’t matter what – just do something and at the end of the day, learn all there is to learn from your successes and your failures. Just approach whatever you do with an open mind, and when the potential loss is minimal, take that extra risk with only knowledge to gain, and in the end you’ll walk away a smarter and better person.

    Edits for grammar and to remove Word formatting…

    Posted in Failure, Self Improvement, SEP Blog Battle | No Comments »