Posts

Showing posts from 2020

ChatGPT - How Long Till They Realize I’m a Robot?

Image
I tried it first on December 2nd... ...and slowly the meaning of it started to sink in. It's January 1st and as the new year begins, my future has never felt so hazy. It helps me write code. At my new company I'm writing golang, which is new for me, and one day on a whim I think "hmmm maybe ChatGPT will give me some ideas about the library I need to use." Lo-and-behold it knew the library. It wrote example code. It explained each section in just enough detail. I'm excited....It assists my users. I got a question about Dockerfiles in my teams oncall channel. "Hmmm I don't know the answer to this either"....ChatGPT did. It knew the commands to run. It knew details of how it worked. It explained it better and faster than I could have. Now I'm nervous....It writes my code for me. Now I'm hearing how great Github Copilot is - and it's built by OpenAI too...ok I guess I should give it a shot. I install it, and within minutes it'

Architectural Characteristics - Transcending Requirements

Image
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

Laws of Software Architecture

Image
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

Consensus: The Hard Kind

Image
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

Mentoring a Software Engineer

Image
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

Grow Your Career, Be A Senior Engineer

Image
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

The Terms that Blind Us

Image
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

Why are Distributed Systems So Hard?

Image
Isn't it true you can just write deterministic code and if you do it right and work to fix all the bugs, eventually you'll have a simple that never does the wrong thing?  If that's not the case then why not?  Computers are deterministic - they're predictable and they only ever do exactly what you ask them to do and nothing more...right? It's complicated. On a single node (computer) most failures mean the entire node completely stops working - for example the power supply fails, the disk dies, or the motherboard gets fried.  These types of failures are easy to detect because the node won't be in a 'partially failed' state where sometimes it performs the functions it's asked and sometimes it doesn't. In a network, you have multiple nodes - possibly hundreds or thousands.  When one node fails, it is impossible to be 100% sure that node is completely down.  And if you can't be sure that a node won't come back to life, then you can&#

Cluster Management at LinkedIn

Image
In 2014 LinkedIn released a cluster management solution called Helix. Helix solves some problems that arise when a system scales to be too large to manage even on just a few hosts. A successful system will start to go through a few transition states that, when large enough, will become frequent enough to require an automated solution. First, your system will become too large to host on a single machine. So now you need to shard it. Then your system will either have hosts fail once in a while, or some shards might start getting too big or taking too much load. So then you can start using replication to solve for that. As your cluster grows, the average size of shards also grows - sometimes you’ll have to split shards because they become too big, or more broadly redistribute. So now you need something to allow for that. Partitioning/sharding, fault tolerance and scalability - these are the higher level concepts just described, and the problems Helix solves for. If you can sol