• Mar
    10

    “stand-up” meetings are more popular than I thought…

    by Matt Terry

    I recently came across a post about a “22 minute meeting”.   The claim seems to be that shorter meetings are more productive and efficient.

    Most of us here at SEP have already had the “culture shock” of a stand-up meeting.  In my experience it has been a very beneficial way to deliver information and get the entire team together, without completely disrupting any momentum that the team already had.  Most of the time, our meetings were less than 15 minutes!

    I really like the fact that this style of meetings is taking off in other industries.  Ideally, our mission states that we are going to create success for our clients…perhaps we could start small by helping them become more efficient.  I think that the biggest improvement in these types of meetings is the lack of distractions…I see lots of people doing OTHER things while we are trying to have meetings – it rarely helps.

    At any rate, there is a neat little poster that Nicole Steinbok made to describe this process.

    Tags: ,
    Posted in Business | No Comments »

  • Mar
    1

    Developers’ libraries…

    by Matt Terry

    Being that my background is primarily with embedded software (namely, C and C++ w/o the .NET framework), I have not had much experience with online libraries. They seem awesome in theory, but for my application I struggled to see a need for them. And therefore, I was shocked at how much work people put into said libraries.

    This was all true…until recently. My 3 years of working on embedded projects here at SEP has ended, and now I have started helping with some of the early stages of a mobile app.

    My domain is definitely NOT mobile, but I would say that it isn’t that drastic of a change. And if my knowledge of software was in a Venn diagram format, I don’t think object oriented programming would be in the center.

    So, in order to be as helpful as possible on this new project…I decided to educate myself on the mobile platforms that we will be using – Android, Symbian, and of course…iPhone.

    There’s a lot of information out there.  Most of the time, I find myself going to multiple sites for that information, though.  One thing that has really impressed me so far is the work that all three of these platforms have done, in the way of documentation.

    The Android library seems to be the most fluid, and easy to navigate.  All of the native packages and classes are easy to get to, and easy to read.  They even include examples of how each can be used.  Way cool, IMO!

    The Symbian library seems to have a TON of information…literally.  It’s so much information, I find it difficult to find what it is I’m looking for.  Some of that might come with my lack of knowledge about the platform, though.  Under 1 site, we have documentation for the OS, APIs, hardware (and different versions), etc.  It’s quite the mother-load of information.

    The iPhone library seems to be broken up into a completely different format.  Different being the key word.  Android chose to break it up by package and/or class.  iPhone seems to have a different method.  I’m sure I’ll like it better once I get neck deep into developing an app for the iPhone…but for now, I find it difficult.

    To me, it is amazing how much time each company has invested into these libraries.  That’s not something that they are going to directly see any benefits from.  Immediately, you can tell that they are trying to make the developers happy!

    “Daddy like”

    Tags: , , , ,
    Posted in Software | No Comments »

  • Feb
    4

    To document…or not to document…

    by Matt Terry

    As an engineer, I tend to error on the side of “this should be documented”. However, I think that with the recent push of being agile and lean, the word “documentation” has a bad connotation that comes with it.  I never realized that people might have a different definition of the word “document” than I had.

    Here recently, I’ve been working on training a group of developers that work with one of our clients.  I started off showing them all of the product’s documentation…SDD, PRD, SRD, UIRD, and other acronyms that mean a lot to some people, and very little to others.  I made a point to show them the documentation to begin with, before diving into the software itself.  (This was mainly done to show them what documents to expect changes from the client in.)

    Sometime later during the 4 weeks of training, we began looking at an engineering tool that we created internally.  This tool had very VERY few in-code comments.  This tool was not intended to be maintained, nor was it expected to be seen by others.  It looked pretty bad, and was difficult to explain what some of the longer functions did, without combing over each line of code.

    The day after we trained on this tool, I mentioned that they might want to begin documenting the tool if they found themselves using it more than the 1 week we used it during training.  Then a LOADED question was asked….”what format should we document this tool in, and should the document be in the PLM (Product Lifecycle Management)?”

    Well, that’s when I realized that my definition of “document the code” and their definition were not the same.

    Summarized into my own words…

    Software Documentation:  Low/High level DETAILED documentation, often referred to as a manual.  I typically think of this as a document that lives in some sort of configuration management tool.

    Annotation:  explanatory comments added to your work after you’ve written it.  I typically think of this as in-code documentation.

    So, back to the question…to document, or not to document?

    Since we have been changing into this much more agile and lean group, perhaps we should change our lingo as well?  Moving forward, I believe I will use the term “annotate”.

    There are other places where such lingo is changing.  I am challenging myself to be more mindful of these changes; and more importantly, to implement them when speaking with others.

    Tags: , ,
    Posted in Software | 2 Comments »

  • Feb
    2

    Choose Your Own Adventure, SEP style…

    by Matt Terry

    Do you remember those Choose Your Own Adventure books? It was great because depending on what you wanted, you could change the beginning, middle, and end of the story. Sometimes it feels like that’s how SEP’s career path system works.

    At SEP, we have a system that allows an engineer to basically create his/her own career.  (I say basically, because we still have roles and job descriptions…I mean, you have to have that kind of infrastructure for this to work, right?)

    This became much more obvious when I finally heard someone else talking TO me about my own opinions of our career path.  (Does it ever take someone telling you what you said, for you to actually hear it?  Sounds like a topic for a future post…thanks me!)

    A co-worker, and good friend of mine, Anthony told me that he looked at our skill matrix, and asked some of the managers how he could improve in a specific area.  So to me, it seems like Anthony is able to choose his own adventure.  At SEP, if you want to pursue a certain title/role…you can simply look at the skill matrix and job descriptions, or ask your manager, to find out how you can improve yourself to achieve such a role.  Obviously it still takes more than just reading and learning to fit into a role…you have to BE that person and DO that job, also.

    In my experience, this is unique to SEP.  Also in my experience, this doesn’t work well for everyone.  Some people will struggle with not having obvious and finely-structured career paths, or a manager that tells you exactly what you need to do for your next promotion.  Some will excel in this environment, others won’t.

    I, personally, like the idea of choosing my own adventure.  I also like the fact that I can choose to go at my own pace!  Each year will be different and my ability to excel in each area might not be the same as the previous years.

    Tags: , ,
    Posted in Career Path | No Comments »

  • Oct
    8

    Things recruits should be mindful of…

    by Matt Terry

    By actively being part of the recruiting team at SEP, I get to speak with many college students that are looking for internships, co-ops, or full time positions.  I feel like it is part of my job to help out with the recruiting here at SEP.  The best part is, I really enjoy meeting and talking with people who are getting ready to begin their first career, or even start a new career.

    Many of the people I meet are what I would consider to be an “ordinary” recruit.  This isn’t necessarily a bad thing.  An ordinary recruit would be someone who is memorable and has a resume that is both applicable and informative.

    However, some of the people I meet are what I would consider to be a “notable” recruit.  This can both be a good thing and a bad thing.  A notable recruit would be someone who makes a lasting first impression.  This first impression is key, in my opinion.

    When it comes time to interview a recruit I will remember things like:  were you dressed for the part, did you show interest in our company, did you ask questions, etc.  To be on the positive end of “notable”, a recruit should be conscious that a first impression might be the only impression.

    So, for all of you recruits out there…here are a few things that you should keep in mind when attending a career fair, meeting with a recruiter, or interviewing for the first time:

    • Don’t wear your pajamas when you come to talk to someone.
    • Be curious about the company, culture, type of work, etc.  You want to get an idea of what the company is and does.
    • If you have a “goal” on your resume, make sure to tailor it based on who you are meeting with.  For example, if you are meeting with a software company – tailor it to software.  If you are meeting with a hardware company – tailor it to hardware.  Don’t have a generic “catch all” goal.  The only signal that sends to me is that you didn’t plan ahead.
    • Spend 15 minutes to read over the company’s website before you talk with that company.  This is a great way to start up discussions – location, recent news about the company, company blogs, etc.  This is also a great way to show that you’re interested.

    There are not any set rules, but if you were talking to me…these are the kinds of things that I would remember about a first impression of a recruit.

    Tags: , , ,
    Posted in Recruiting | 3 Comments »