masudio - tech

Building a system means meeting a set of requirements dictated by the customer.  But the customer isn't always going to translate what they want into engineering terms.  Even if you say please, they might not even know how.  If they ask for an online ordering system, they probably won't specify that it needs to be available 24/7 and auditable for tax purposes.  Yet these aspects could mean the difference between project success and failure.  Those unsaid aspects are called anything from 'nonfunctional requirements' to 'Architectural Characteristics'. In their book 'Fundamentals of Software Architecture', Ford and Richards define Architectural Characteristics to have 3 criteria: Specifies a nondomain design consideration Let's dive into these bullets to better understand them. Aspects of Architectural Characteristics Specifies a nondomain design consideration If you're building an ordering system, then order numbers, customers, items and prices ar

As the discipline of software engineering matures, few things remain constant.  A few years ago, a large portion of the community thought that TDD was always the best methodology to use - after all, you move faster by being thorough and preventing bugs.  Nowadays it's clear that unit tests do not ensure a successful project - when you're A/B testing new features or products and you're not even sure if your code will be around 3 months from now, it's better to churn out production code and test it in prod.  You can clean up the mess later, if the business value makes it worth it. But despite the pace of change in software engineering , in software architecture  there exist a set of 'laws' which don't change over time and which apply to all architectural endeavors.  I'd like to talk about 2 of them in this post as they are important ideas to keep in the back of your mind as your skills grow past coding, past design and into architecture. Laws of Software A

You're on a team, undoubtedly.  You have been tasked with solving a customer problem and you have a design ready and waiting for review.  One team member reviewed an early version and asked for some tweaks, but after an iteration they agreed it was the optimal path forward.  You open it up to a wider audience for further review.  But then another team member pipes up... "This design doesn't work - it's just not possible with our current setup" Well, damn!  What do you want me to do?  Do I need to cycle through every team member and get them to give their feedback, iterate and incorporate it and then present it to everyone?  Even if I do that, by the time I get around the group, someone will disagree with the design again! Calm down, breathe - this is what it feels like to learn.  And what you've just experienced is what I like to call the 'Hard' version of Consensus. Every team is different in how they deal with this consensus problem, but if the input

Whether it's about raising a small child or directing a full grown engineer towards her next promotion, mentoring requires a great deal of patience, honesty and self-awareness.  One wrong step and you could trigger a shame spiral.  Or just as bad, you could push your mentee to leave the team for a place with better career and/or learning opportunities.  There are clear rules of engagement to follow, but once you've mastered those, doing it right becomes an art more than a science, so bring your creative energies in order to drive excellence. A common next step after becoming a competent contributor on a software team is to start helping others onboard.  When a new teammate joins, having a mentor can accelerate progress by showing them the next steps in their career path rather than letting them hack it out on their own. But being successful as a mentor can mean many things - the KPIs for mentoring are not as clear as technical projects.  You need to have the trust of your manag

My personal experience with navigating a career in software engineering has been dotted by fits and starts.  9 years into my professional life I can look back and see what worked, what didn't, and why.  I want to share that knowledge so other young engineers can do more with their first 9 years than I did.  Plus it's just fun to reminisce and will help me visualize the next steps in my career. To be clear, the north star goal in my career is and has always been to learn and grow towards more positive impact on those I serve.  If you have the same or a similar goal, this article will be useful. I wrote up a simple formula which I think can help any aspiring engineers out there.  It can be used as a template for a career plan.  When you're thinking about how to get to the next level, make sure you're putting equal emphasis on all these categories.   1.) ACTION from you, despite imperfect information 2.) COWORKERS whom you respect 3.) MENTOR(s) invested in your growth and

Blacklist.  Master-Slave Architecture.  Black Hat.  These terms helped build the foundations of software development as we know it today.  But do they support the narrative that black is bad and white is good?  And that having masters and slaves is ok?  Is it a racist act to continue to use them? Let's first address the 'rolling my eyes' crowd.  It's true that, given the power of God, of all the things to change with a snap of your fingers, this one wouldn't be the first.  Let's describe, to the best of our ability, the argument that we should continue using these terms: "these terms were not introduced with the intent to hurt people or make black people think they're less-than.  They're just part of a common vocabulary, and having that is important to the field of software development.  We need to be able to communicate with each other efficiently, and if we don't use the words that are already well-understood by most engineers/developers, then