Fauie Technology

eclectic blogging, technology and hobby farming

Category: software development (page 3 of 3)

Five Features of a Successful API Platform – PDF

'API Culture'

I've coined this phrase to help indicate a healthy technology organization that strives to build a solid set of capabilities that can be leveraged across a wider audience than an engineering team typically gets.

Building an API is more than just writing a web service.  It's more than using AJAX or using a REST Framework within your code.  Building an 'API Culture' is all about providing your development teams the structure and ability to be as effective as they can be.  Increase collaboration, increase code quality and increase the reuse of applications that they build.  We're not talking about a specific tool or methodology, instead, we're talking about an attitude that your teams will adopt in order to enjoy their day to day working life a lot more.

Read the rest after a free download –

    Enough About Enough

    One of my last posts was all about work life balance, “Your work life balance sucks“.  We all have issues with prioritizing our time and allocating enough in each bucket of our lives.  Family, Work, Self, Others.  Here, I want to talk about your knowledge and how it’s important to be intentional in that aspect of your life too.

    I seem to be surrounded with people who either know the nitty-gritty detail about the technology or subject matter that they are engrossed in OR the stereo-typical “jack of all trades”.  You know the two types.  The first, you can’t have a discussion with about something.  They know WAY more than you do, and take the conversation very deep, very quickly.  They miss the forest for the trees.  These are your experts.   This person knows the insides and out of the tool you’re using, and their knowledge allows you to be confident in your approach and whether an idea will work or not.

    The second type of person is the typical ‘jack of all trades’.  I say typical, because in this case, they know a little about a lot.  I’d even say, a little about ‘some’ things.  In the technology world, this person would be able to work around a bash shell, write database queries and make some updates to a web page.  The counter to this, is the Java developer who doesn’t know how to write a query.  The web designer who doesn’t know a lick of HTML or CSS.  My point here, is that this person is wide and shallow, as opposed with the first person, who’s super deep, but very narrow.

    The mental image just came to me of the iceberg.  You know, something like this:

    The first person will tell you about that little piece of ice that sits at the bottom of the iceberg.  While that’s important to someone, and is completely valid knowledge, 99% of us don’t care, and unless the conversation is about the bottom tip of the ice berg, it’s inappropriate.

    The second person, they can tell you generally about ice bergs: maybe only if it’s covered in snow. If it’s just ice, they may not know about it.

    The challenge a lot of us have, is how to balance in the middle of this scale.  Depending on your role, you need to find your sweet spot.   For me, as a consultant/architect/VP Engineering, I need to know “enough about enough”.  I need deep and wide.  I’d argue that I have to know 80% about an iceberg, but more importantly, know how ice works enough to be able to make some assumptions that can later be validated or experimented on.

    In the world of technology, this manifests in a lot of different ways.  Mostly, it comes down to being educated enough to decide between two or more options, and picking an initial path go down.  Now, anyone can pick the path, but, the sweet spot means being able to get to the fork in the path as soon as possible to determine if it’s the right path or not.  Which database engine do we pick? Which time-series data storage do we use?  Which visualization engine will work with our python framework, etc.

    There’s absolutely no way everyone can know everything about everything.  Seriously, look at the eco-system for devops these days (Back when I was first writing code, we didn’t have no automation!).  It’s amazing!  There are dozens of tools that do almost the same task.  They overlap, they have their sweet spots too, but it takes a special kind of person with a very specific set of skills (hmm.. I’ve heard that somewhere), to determine which tool to use in a specific situation.

    I want to say this is another instance of the 80/20 rule, but not exactly.  Let’s go with that anyway.  Instead of learning the 100% details of something, spend 80% of the time, then keep going on to other things.  Don’t be so narrow focused.  Think about the days of Turbo Pascal.  If all you knew was 100% TP, how’s the job market these days?

    Balance that with only learning 20% about something.  You will never be seen as an expert.  No matter what the subject matter is:  Technologies, development approaches, managerial styles, etc. You need to be deep enough to be an authority to make an impact on the organization you’re in if you want to excel and succeed.

    Everything in life needs a balance.  Diet, exercise, hobbies, work/life, etc.  Knowledge and learning is in there too.  Be intentional about where you focus your energies in learning about something new, and figure out how much is enough.

    3 Behaviors to Empower Developers

    I’ve spent 15 years of my professional career writing software.   Over time, my role has changed so I’ve been in the trenches in different companies and industries.  We start at neophytes.  The company is new, the technology is probably new, the processes are unknown and there are people all around that know more than you.  As time goes on, we become more senior.  Hopefully we start influencing the work we do and continue to provide added value instead of just writing code someone else told you to write.

    No one wants to go to work and be bored (well, that may not be true, someone told me they didn’t want to try new things, didn’t want to learn anything else and just wanted to keep doing what they’re doing.  I couldn’t imagine!).

    Through the ups and downs of a career, I’ve been in good teams, bad teams and mediocre teams.  Here are three behaviors that I have observed that have helped me succeed and implemented to help others succeed.

    Allow them to fail

    Hear me out here.  If I only failed, then I wouldn’t be affective.  My job is to deliver technology solutions and technology teams that deliver a product.  This product has to work.  There have been times though, that I pushed the boundaries to try something new.  Usually it’s by bringing in a new piece of open source technology or building a new capability on a platform.  When it works, awesome!  When it fails, oh well.  Lesson learned. Time to try something else.   If I were punished, or fired every time I failed, I would never try anything new.  I’m thinking back to a very specific activity that pivoted a startup I worked at.  It pivoted the entire function of our platform and put us in a new market.  That market provided a ton of opportunity to integrate with technology partners, and eventually be acquired.

    The key rule to failure, is to fail fast.  Junior developers typically take too long to learn something new in order to fail fast.  This is not a knock on junior developers.  We’ve all been there.  If a developer is able to pick up a new technology really quickly, they can quickly figure out if it fails.  Celebrate it.  Encourage it!

    Get out of the way!

    One of my favorite mandates of Agile/Scrum is the sprint.  By defining a sprint, the process locks in the the workload an engineering group is going to work on.  By defining a one or two week sprint, there’s an entry point to the development process.  Product managers get to completely guide WHAT will be worked on.  (More to come on the importance of Product Managers, I can’t WAIT to talk about that one).   Before a sprint starts, you need a collaboration of executive management, product management and engineering to figure out what’s next.  Once that’s determined, GET OUT OF THE WAY!

    A primary tenet of mine is to tell an engineering team what you want done, not how to get it done.  This is critical to allowing your teams to learn and grow.  They are the technologists, and should know more about how the code and everything works more than people outside of that group.  Let them figure out how to solve a problem. Give them big problems! They’ll surprise you.

    Nothing is more frustrating than being distracted when we’re coding something.  Developers get in a groove.  For me, it’s like music.  If you’re in a quiet room, rocking out to Linkin Park (like I am right now), and someone comes in and shuts off the music and turns the light on, it takes time to get back in the groove.  It’s exactly the same when we’re coding.

    Knock down roadblocks

    This bullet point is the hardest one to document.  During the creative development process, the last thing you want your engineering group doing is coordinating with sales, or coordinating with facilities to make sure a room is booked for a meeting.  As a development manager, those are things I will deal with.  If you’re a scrum master, that’s what you should deal with too.  Our jobs are to enable our engineering teams, not make them do ‘other’ work.

    This may sound backwards, but it follows the ultimate ‘servant leadership’ guidelines.  Most people would look at pay grades or years of experience and think “They’re only a developer, I’m a <much higher pay grade> employee, they can do the grunt work”.  I believe that in order to be the best enabler of an engineering group requires us to take care of that ‘other’ work, and let them focus on what they’re passionate about, and allows them to add more value!

    Thanks for reading.   This is cross posted at LinkedIn:



    Newer posts »

    © 2022 Fauie Technology

    Theme by Anders NorenUp ↑