Tag: productivity

Movember Wrap-up – Weekly Article Dump

Movember Wrap-up - Weekly Article Dump

Movember Wrap-up

At the start of December, it’s time for a lot of us to shave off our glorious Movember badges from our upper lips. This year, MoMagnets did an absolutely amazing job raising money for Movember. At the time of writing, we’re sitting at just under $2400! An incredible effort by Magnet Forensics and all of those that helped with their generous contributions.

My ‘stache didn’t quite get to where I wanted to this year. It was close, but it was another connector-less Movember for me. I was almost able to get some twisting done for some not-so-legitimate connectors. Oh well… Here’s what I ended up rocking for most of the month:

Movember Wrap-up - Nick's Final 'Stache

My final Movember creation: The Anti-Connector.

Matt Chang definitely took the lead for raising the most of all the MoMagnets members at over $700! Mica Sadler is sitting in second at just under $400. That’s nearly half the team’s total between these two beauties. We also had a very gracious contribution from our CEO that I wanted to call out. Thanks so much, Adam!

There’s still a bit of time left before donations are closed for the 2013 Movember season. We have until the 9th to get some final contributions in! If you’re feeling generous, please visit our team page and make a contribution. Every little bit helps, and we greatly appreciate it!

Articles

  • Top 5 Reasons People Love Their Jobs and How You Can Love Yours, Too: Some great points on why people love their jobs. Some of these may be pretty obvious, but it’s important to be reminded about what keeps people engaged. Among the top things: the work culture, the amazing people you get to work with, and autonomy. If you’re trying to create an awesome place to work (or if you’re looking for an awesome place to work) then these are probably things you’ll want to focus on!
  • 5 Things Zapping Your Company’s Productivity: Ilya Pozin always has some interesting articles. This article takes the perspective that some of the fancy perks or awesome processes you have in place may actually be hindering productivity. One common theme that was brought up under two separate points in this article is that sometimes people need a spot where they can work in peace. People like having an fun collaborative culture, but many personality types require some quiet time in order to buckle down.
  • Reduce Your Stress in 2 Minutes a Day: I’m not the type of person that truly believes doing one tiny thing for only a moment every day is going to have an enormous positive impact on your life. However, I do think that if you can take the time to try and do a few little things here and there, that overtime, you’re likely to have more a positive outlook. In this article, Greg McKeown shares a few tips on relaxing and trying to regain some focus. I don’t think it’s anything that’s going to be life-changing, but it never hurts to think about different ways to catch your breath.
  • Building a fast-failure-friendly firm: This was a pretty cool series of slides put together by Eric Tachibana that I thought was worth sharing. There are lot’s of articles on failing and why it’s important–especially for innovating. This series of slides provides a high level perspective on how you can approach failing… the right way!
  • Code Smells – Issue Number 3: This is an article I wrote about Code Smells. This entry talks about the use of exception handlers to guide logical flow in your code and alternatives for when your class hierarchy starts to get too many very light weight classes. As always, I’d love to get your feedback. If you have other code smells, or a different perspective on the ones that I’ve posted, please share them in the comments!
  • 5 Bad Thoughts That Will Throw You Off Track: This short little list is worth a quick read through. There are a ton of things that distract us every day, but the distractions you can easily control are the ones that you cause. Examples? Don’t take on too much at once. Don’t try to make every little thing you do perfect. It’s a quick read, but well worth the reminder!
  • Not Crying Over Old Code: Another programming article for this week. As the article says, the common meme for programming is that your old code is always bad code. However, there should be a point in your programming career where old code isn’t bad, it’s just different than how you might have approached it now. If your always experiencing your old code being bad, then maybe you’re not actually that great at programming yet! Or… maybe you’re just too damn picky.
  • Things I Wish Someone Had Told Me When I Was Learning How to Code: This article by Cecily Carver is something I’ve been hoping to come across for a while now. It’s another programming article–a good read for experienced programmers but incredibly important for newbies to check out. Cecily covers some of the roadblocks you experience early on, like code never (almost never) working the first time, or things you experience throughout your programming career, like always being told of a “better” alternative. I highly recommend you read through this if you dabble in programming, or if you’ve ever considered it.

Please visit our team page for MoMagnets and make a Movember contribution if you’re able to! Remember to follow Dev Leader on social media outlets to get these updates through the week. Thanks!

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


Halloween – Weekly Article Dump

Halloween at Magnet Forensics

Happy Halloween

Happy Halloween, everyone! I hope those of you who were out and about with your own little ghouls and ghosts had a safe Halloween this year.

Halloween costumes were pretty creative again this year at Magnet Forensics. I tried going with my own Horse Lime attempt, but it’s difficult when not many people know what the Horse Lime actually is. Regardless, my awesome mother put together the lime portion of my costume, and I was extremely grateful for that (and yes, I’m in my mid 20’s. No judging). I think it turned out pretty damn good.

This year, Saige won our Halloween costume contest. As Old Gregg, it was hard for that to not be a sure-fire win. Complete with Bailey’s in hand, I think the only thing that could have made it better was a set of watercolours to go with it. Absolutely awesome job.

On behalf of Team Magnet, Happy Halloween!

Articles

  • Kenneth Cole’s 10 Keys to Success: In this article by Teresa Rodriguez, we get a list of 10 tips from Kenneth Cole on success. While I don’t think there’s anything groundbreakind about them, I do think they’re all relatively straight forward. My main take aways are being innovative, being passionate about what you do, and create value. This article also has a bit of background on Mr. Cole that I wasn’t even aware of, so that was pretty interesting.
  • Community is Everything: How to Build Your Tribe: This article was kind of unique. It doesn’t necessarily apply directly to startups or business, but I see lots of parallels. Miki Agrawal writes about creating a “tribe” or a community of people around you. It’s really about placing positive people in your life, or go-getters in your business for the parallel. Again, no monumental secret tips in here, but it’s a great topic.
  • Performance Recognition: Cutting the Cost of Disengagement: This one is an infographic (and not really an article) about engagement and performance recognition. There are a lot of stats in there, but regardless of whether or not I trust the accuracy, I think the general points made are sound. Essentially, there are a lot of disengaged employeed in the global work force and it hurts productivity. By creating a culture of recognizing performance, you can help boost engagement which has all sorts of positive effects.
  • Code Review Like You Mean It: The first programming article for this week. Phil Haack discusses how to actually code review effectively. One of the key topics is taking breaks from long code reviews so you can maintain focus. Another is forgetting about the author when reviewiing and focusing solely on the code. Phil even put up his own code review checklist and suggests you have your own. Personally, I think I’ve kept a mental one but it probably would help to have it solidified.
  • Converse, Don’t Complain: This article by Hiroshi Mikitani had the most buzz from the things I shared this week. It really seemed to hit home with people, and I imagine it’s for a couple reasons. First of all, if you’re honest with yourself, you probably complain. You probably chat with at least one colleague you’re really close with and just flat out complain with them. You both don’t like something, so you vent. That’s definitely a comforting activity, and sometimes we need it. The flip side is you have authority or responsibility over something that people have problems with. Nobody is voicing any concerns to you (since they are just complaining among themselves) and if they are, there aren’t solutions being brought forward.The first of this two part solution to this is instead of whining, start coming up with potential solutions. It doesn’t matter how big or small your ideas are, start thinking about what a solution might be. The second part is communication. If you want something to get resolved, you need to bring your concerns with potential solutions forward. If you only complain and vent to one person, your concerns won’t be heard. If you only ever whine about something not being correct, then you’re doing a half-assed job at trying to come to a solution.
  • Lead by Example and Emulate Ideal: This one is a plug for my own article. I decided I’d write about why leading by example is actually more powerful than some people think. You have a lot of eyes on you as a leader, and you may not realize it. By leading by example and emulating the attributes you consider ideal, people will catch on to it.
  • Keys to Productivity: I’ve sort of noticed this through my own experiences so far, but early morning and late at night are great times to be productive. When there are a lot of stresses on you during the day, sometimes it feels like you’re not being productive. It doesn’t necessarily mean that you aren’t, but it’s your own perception. Getting a head start on the ay by getting into the office early, or staying up late for your own creative endeavours can prove to feel really rewarding.
  • Build Trust Through Training, Transparency and Trials: I’ve shared articles from this series by Jake Wood before, but this is another standout one for me. Trust isn’t something you can just put into your company values or your mission statement. Trust is something you have to live out each and every day in your organization. We can all say we value it, but if you aren’t willing to live it out, then it’s not something you truly value. One quote I really like from the article is:

    Transparency cannot happen unless your leadership regularly visits the “front lines,” wherever that may be in your business.

  • Here Is What Smart Companies Get That Others Don’t: The first of the three points offered in this article is that smart companies think differently. They are leaders and not followers when it comes to everything they do. The second is that they sell their culture. Their culture is actually core to their business and their organization, not some after thought. The third is that they help others become smarter. Provide value and become something that other people and business want and need to use.
  • Why Good Strategies Often Fall Apart: Ron Ashkenas highlights a few reasons why strategies that look great sometimes just don’t work. The first two points he makes in his article are the ones I want to highlight. The first is passive aggressive disagreement. Not everyone is going to be on board with all parts of all changes, so you’re going to have people that disagree. If the culture does not actively embrace people being able to voice their concerns, it’s difficult to carry out a successful strategy. Individuals might complain, but they wont end up doing anything about it. The second is something along the lines of “being too nice”. Trying to avoid confrontation because you’re afraid of it is a recipe for disaster. If you actually encourage open communication and trust, then being able to have hard discussions about something can be really powerful.
  • Three Things that Actually Motivate Employees: This probably isn’t new to a lot of people, but money (after a certain point) isn’t the driving force for employee motivation. The three things outline in this article are mastery, membership, and meaning. Employees want to be able to mastery their skill sets, learn, and get better at the things they do. Individuals within the organization want to have a sense of community. They want to feel like they align with the people they work with and their working toward a common goal. Employees also want to work on something that has meaning. Work that has a large positive impact is extremely motivating.

Happy Halloween! Remember to follow Dev Leader on social media outlets to get these updates through the week.

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


It’s Our Code

Background

I’m sure what I’m about to talk about here doesn’t just relate to programming–it relates to any team-based project where everyone works on a small portion of the big picture. My experiences are primarily geared toward writing code in teams, so try to find parallels in your own work/experiences if you’re not a programmer. Anyway, enough of that.

When someone puts a lot of effort into something, they’ll often take great pride in the finished product. Of course, it’s great that they do! They’ve slaved away at something at work for days, weeks, or months, and it’s finally working/implemented. Other people are using it and it’s doing its job as expected. Awesome!

What kinds of things could possibly go sour here? If you have experience working in teams to complete a project, you might have some ideas.

Ownership

You don’t own anything. You don’t own a single sentence or character you type and share with your team. You don’t own the title you came up with for the document, the name of a class or interface in your code, the conventions for indenting your variable declarations, the overall file & folder structure of your code, or even the Powerpoint you want to show to the sales and marketing department. If you’re on a team, you’re creating content for your team and your team assumes ownership of it (technically, I guess your company owns everything you do… but… stick with me on this one for a bit).

Ownership becomes a big problem in team environments. Person A worked on Item X, so Person A is assumed to be the owner of Item X. Now every time someone wants to use Item X, they need Person A. Simple? Yeah, that’s a simple system, but it’s absurd. Why don’t I just work on the most important part of the project, encrypt it, and secure my job for the rest of eternity? It’s hard to swallow sometimes, especially after pouring a lot of time and effort into something, but when you’re part of a team you should always be working in order to create things for your team. This has two major benefits:

  • You’ll adjust your perspective to be that of your entire team when you’re making something. (i.e. Am I working to their standards? Am I using their conventions? Can someone else understand what I’m writing here? Will this be easy for them to use? Can someone easily come along and modify my work to improve it in the future? etc…)
  • You remove the people bottleneck.

Ask the Experts

Instead of ownership, people should be considering “expertise”. What’s the difference? Well, someone who owns something is entirely responsible for it. If you want to use it, you ask the one owner. If you want to change it, you ask the one owner. If someone asks you about it, you better direct them to the one owner. The one owner becomes the bottleneck for whatever they own.

An expert is someone who has extensive knowledge in the area and there can be more than one. If you want to use something, you consult one of the experts for proper usage. If you want to modify it, you consult the experts. If someone asks you about it, you can direct them to any of the experts. See the difference? You widen (or eliminate?!) the bottleneck. You increase how robust your team is in terms of responsibilities.

What happens if Bob is sick for a week and he’s the only one who knows how to use the data layer when a big customer bug comes in? What happens when your co-op student who wrote your patented fizz-buzz algorithm leaves to go back to school and no other developer knows how to maintain the code? If there’s only one owner in each of these situations, you’re in a bad spot. If there are several experts who are knowledgeable in the area of code in question, you’re laughing.

Keep in mind, there aren’t only changes in your development staff–your code base is dynamic too.

Code Changes

One huge benefit that software has over almost any other product is that it’s dynamic. You can build something now that works, that may not work next week, that can be fixed the week after, and then later completely rewritten the week after that… and… well… you get the idea. Sure. I know you’re capable of thinking of situations where this doesn’t work with software or products that can somehow get the same benefit, but I’m not contesting that. The point is that software is (usually) flexible and dynamic and you need to treat it like that.

When a group of people has control over software, they can guide the direction it grows in. You get multiple people who are knowledgeable in the direction that the software can take and you leverage the group’s knowledge and experience collectively. Obviously consulting every single person on the team to change a single line of code is overkill, but at least you can find a happy medium in terms of architectural and API changes.

Your code changes because unless you executed the waterfall approach to programming 100% perfectly, your architecture is likely going to change. It’s just a fact of life. But there’s absolutely no reason to freak out. Embrace it. You’ve written unit tests for a reason, right? You’ve used interfaces and designed a nice clean API to decouple your code and make such changes easy. Duh! So don’t worry! You have a couple experts in the area of code that needs to change, so either they can tackle the changes or guide one of your more junior developers.

The same thing should hold true for any process or on-going project that is dynamic. Take measures to ensure that changes in the project or workflow can be done by anyone and don’t jeopardize the whole operation.

Tips

Here’s an assortment of tips (and hopefully some parallels for the non-programming types):

  • Use some sort of revision control. When something bad happens with your work, you always want the ability to press a figurative undo button. Look into something like Git, Subversion, or Mercurial. There are others out there too! Source control software isn’t just great for programmers… If you’re collaborating on a document of any kind, you can leverage source control to manage the revisions of the document.
  • Use tools that allow working on things in parallel. Again, source control helps here for programmers… but find solutions that mirror this. Look at Google Docs! You can literally work with people at the exact same time!
  • Practice and embrace the fact that you don’t own anything… It all belongs to your team, collectively. Keep that in mind or your team may start finding better team players! You want everyone to feel like what they are working on is for the team.
  • When you have something that’s dynamic and changes (like code), take the necessary steps to facilitate and embrace changes. Take precautions to ensure changes don’t mess everything up (unit test & code review!)

Summary

When you’re working in a team, you need to be thinking about your team. What you’re working on belongs to your team and shouldn’t be treated as your personal pet project that you control. This works best when you have multiple “experts” that have knowledge in a given area that can make changes or guide others to make the required changes. If you’re working on something that is dynamic or changes often, you can ease some pains by planning for change. Don’t resist it and fall apart when changes finally happen.


Weekly Article Dump

Quick Reading Update!

Here’s a collection of things I shared over the past week. It’s a short list this time around, but a quick reading update right before the weekend might provide you with a couple topics to look into in your downtime:

The goal of these types of posts will just be to summarize my social media activity. If you don’t want to watch Twitter, LinkedIn, or Facebook, you won’t need to. Once per week (on a Friday), I’ll try to summarize all of the articles that I linked to on these social media outlets. For what it’s worth, these will generally be articles geared more toward the leadership side of things and less about software development or programming. Most of what I share in these summaries will be relatively quick reading, since it’s usually just bog posts or LinkedIn articles. I’ll save  book lists and that type of reading material for something else–not these summaries.


  • 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