Some details related to my career track thus far, including various engagements I’ve had, some details related to my core beliefs driving my technology career, and overall outlook on how to grow as an engineer. In a nutshell - my motivation and drive that I credit for getting me where I am today.
Background
I struggled whether this post belonged in the personal or technical stream based on its content. At the end of the decision making process, I decided it speaks to the “Technical Learnings” side of my approach to content and, therefore, makes sense to place into the technical stream of information. Keep in mind that there are, however, personal aspects to this post, but they exist in the context of my Engineering/technical career.
Pragmatic Approach - The Details
On more than one occasion I have had an entry-level or more junior engineer ask me what they need to know or learn to get where I am today. That is not to say that I am an exceptionally successful engineer, but it does credit the fact that my career track is desired by many other engineers in my field. Because it has happened more than once, I’m going to try and put into words some of the life skills and core competencies/values that I firmly believe in and follow. This post is focused on my career as a software engineer - that is to say, someone who works in the world of software and system design, and while I believe some of the competencies and values listed are universally applicable to engineering, I can say with certainty they all apply.
I will call out that along with the core concepts in this post as they relate to maturing as a Software Engineer are explanations of my perception of the job market and hiring in the engineering space. This post does offer some ideas, concepts, and theories to live by as an engineer, which makes it a perfect place to also comment on the current-day situation as it relates to hiring, managing, and working with Software Engineers.
I’m also going to preface this entire post with the fact that I am by no means an author or English major (as I’m sure you can tell from my other posts). I don’t believe I can do the subject areas justice under each category below, but if nothing else, take the category headings/1-liners as the intent of my discussion. In addition, your mileage may vary (YMMV) in any of the suggestions I’ve made - this is not meant to be a conclusive “the way you must operate” by any means. Take what I’ve offered and tailor it to your specific needs, skills, an interests (see my section on “Mimic Behavior” to see what I mean by this).
Take Pride in Your Work
Have you ever been to an art/craft show and seen a master wood carver, glass blower, painter, or some other art-based craftsman glow as he/she presents their products? These craftsmen take pride in their works of art, and you should be no different in your Software Engineering career.
As Software Engineers, our craft is design and code. Learning best practices for how to do something is a fantastic way to not only feel good about what you’re designing, but move in the direction of perfection as well. If you are writing code, comment it. Format the code per the style guide of the language you are coding in. Make sure you don’t mix whitespace and tabs. Don’t mix camel-case and underscore-based variables. Keep your GitHub account well-documented and clean. These sound like extremely nit-picky things, but honestly some of the best engineers I’ve encountered are those that take the time to go back and refactor their code for visual perfection as much as functional perfection - doing so demonstrates both an attention to detail that is unchallenged as well as pride in the work you are doing. Writing code is an art (or can be), and your code is a direct reflection of you. Anyone can write a script (just like anyone could paint a picture), but professionals of their craft do so with pride and demonstrated mastery.
On the architectural side of Software Engineering, the same is true. When designing and architecting solutions, do so in a way that demonstrates you are proud of your design. Consider fault tolerance. Anticipate large scale based on the success of your product (and how you would achieve such scale). Test the design hypotheses (don’t just take them at face value). And when it’s all said and done, document and explain your finished product as though it is the core of your existence. This may sound slightly strange, but if you are truly invested in what you are doing, this will come naturally and the people who you are explaining it to will appreciate your enthusiasm and precise nature.
Data is King
One of the more common complaints I had in my more junior years was related to declarations for root cause on issues without any proof/background. In the world of science and engineering, data is king.
When I use the term “data”, I mean raw data that drives mathematical conclusions. Too often a manager will ask for a root cause analysis of a problem and the engineer will respond with something along the lines of “it was an isolated incident and we don’t expect it to happen again”. My question in these circumstances is always “why, what makes you think that”? I’m looking for proof - if you believe that this truly is an isolated incident that is fine, but justify your position. Anyone off the street can make declarations such as this, but an engineer is genuinely curious as to why something has gone wrong and, as such, will dig until they have either identified the data pointing to the reason, or be told the effort is not worth the impact at that time.
Aside from issues, performance benchmarking is extremely vital to managing business expectations. Open source software is rampant in the industry today (rightfully so) and there are some VERY ill-documented performance characteristics of software suites used for large scale applications. If you choose to use these types of applications/software (or even if you are designing your own software systems), and you are concerned with performance, make sure you understand how the software works and how to benchmark it to achieve the performance and scale metrics you are looking for. Environmental conditions play a huge part in how the system operates in your current ecosystem, and taking documentation about the project at face value will almost always result in catastrophic failures (think, house of cards) at 3AM when you’re on-call. Develop tests based on your understanding of the software, collect data, analyze it, and share/publish it.
All this said, this section is a long-winded way to encourage you to ensure that the declarations you make can be backed by data and good proof (metrics/math) - any respectable and seasoned engineering manager will expect such information.
Be Curious and Stay Current
As I review resumes of people who come across my desk, as of several years ago, I’ve realized gone are the days where an engineer of our generation stays at a company for decades (not that we’ve had that much time to do so quite yet). Young, talented engineers are jumping around in the Software Engineering space more frequently. Employers who practice very old habits of wanting a ‘career engineer’ are shying away from these individuals. In some cases, this makes complete sense (there is inherent overhead associated with on-boarding an engineer), but in others, they are missing out on a potential opportunity to capture cutting-edge skill sets.
Technology is changing rapidly, as are engineering concepts in the software world. Staying current gives the employer the cutting edge they need to keep their business in the newest technology and design concepts, leveraging the benefits that come along with it. Many companies simply do not (or cannot afford) to have their engineers prototype with new technology or concepts, so it is left up to the engineer to figure this out for themselves in their personal time. While this personal exploration is and should always be an expectation (and in my opinion, a natural exercise by a curious engineer), it doesn’t always happen, which leaves the company behind the curve of benefits.
Given the lack of time, effort, risk, etc. available by some companies, it makes sense to look at engineers that have “moved around” frequently. These engineers are typically the ones that are looking for the latest and greatest technology stacks, or the ability to engineer/implement them based on their background (of course, you have to ensure you do your due diligence and make sure these are in fact the reasons for the engineer moving around, and not a performance-based issue). Leveraging someones’ energy, exploration, and acquired skill sets in cutting-edge technologies can generate many huge benefits to the tasks you’re working on.
From the engineer’s standpoint - I can’t endorse or necessarily discourage moving around frequently. However, I can HIGHLY recommend that no matter what, you find a way to learn new technologies, even if they aren’t directly related to your core business responsibilities (of course, in this case, doing so off-hours unless your company supports such an exercise). It’s entirely your responsibility to spend your personal hours learning and staying current in order to progress in your career, and in my opinion, is what differentiates technology leaders from the do-ers.
Operations - Learn It, Know It
Software Engineering is a conglomerate of concepts. Most recently (or perhaps not so recent) there has been a term coined that describes the cross-section of software development and true operations (bear with me as I cringe): DevOps. Although I cringe, I still use the term (quite frequently) given that the industry seems to enjoy it.
So, what exactly is DevOps, and what differentiates it from Software Engineering? This is where I have a problem with the term. Since I’ve been in the industry (in my very short tenure as compared to some), I’ve always had an eye on the operations side of the house - servers, virtual machines, load balancers, etc. Learning these concepts has helped me become a better engineer. DevOps has some of this overlap as well, and also focuses on software delivery automation (think continuous integration/continuous delivery). In today’s world, however, I would be hard pressed to hire a “Software Engineer” who does not understand infrastructure. Designing, testing, and being completely responsible for software entails the full life cycle of said software, including the infrastructure.
Companies at the edge of technology and software patterns are no longer looking for specialized engineers but, rather, those Software Engineers who can design software in tandem with the operational architecture of said software based on the environment they are deploying to. For instance - if you are developing a software application that is a REST endpoint, you will obviously (or maybe not) want to make sure it is stateless. So what does this mean from an architecture perspective? If you’re designing said application, you had better not talk to your operations staff and say “I need 5 virtual machines just in case volume increases”. Not only are you falling into the “Pets vs Cattle” trap (if you don’t know what this is, look it up), you are avoiding the fact that your stateless application could take advantage of auto-scaling capabilities in an environment such as AWS, both increasing the efficiency of your application as well as decreasing the overall cost to the business.
So, this is a bit long-winded, but where does this end up for “DevOps Engineers”? Obviously, so long as the industry calls for them, we will continue to advertise for them. However, specialties in the areas of CI/CD, automation, etc. that a “DevOps” engineer would typically be responsible for should be acquired and practiced by a Software Engineer - in fact, your “DevOps” engineer might just be the Software Engineer you’re looking for.
Learn to Be Versatile
If you look through the various job listings on any of the major job search sites, you’ll quickly notice that every one of the “Software Engineer” or similar job descriptions appears as though they are targeted at a dozen engineers for one single position given the wide swath of requirements. This is a true indicator that employers are (and have been, even if not so obvious in the past) looking to capture that silver bullet engineer - someone who is well versed in both coding, delivery, automation, operations, etc. Although one could argue that these employers are looking for a “know it all” engineer, I believe it speaks more to the fact that the employer does not actually know what its looking for but, rather, knows that it wants someone who can adapt, learn, and be quick on their feet.
Software Engineering takes time, and that time is directly proportional to the amount of knowledge and background you have in the area. Learning how to move quickly and switch gears mid-stream is a trait that is useful in capturing the essence of what these employers are looking for. That is not, however, to say that you should encourage context switching (see future post on this subject). Rather, learn how to capture the essence of a requirement, research it in a way that gets you the minimum required to be productive in the area, and deliver a minimum piece of functionality to test or demonstrate the functionality. The ability to do this quickly demonstrates versatility, and over time, this pattern should become more natural.
Strive for Minimum Viable Product
Many companies are practicing “Agile” these days - and yes, I put that in quotes for good reason. Agile is the trendy thing to do, and has very demonstrated and documented benefits. However, most companies (that I’ve worked for and/or known and heard of) are practicing “Agile” while planning 12 months in advance and constantly changing work mid-sprint (and now you see why I put Agile in quotes).
Kidding aside, there are in fact some very fundamental concepts behind the agile movement that are extremely beneficial. Ability to deliver small pieces of functionality, receive immediate customer feedback, and pivot based on customer feedback are essential to successful delivery of a customer request. One very tangible item that is not frequently mentioned in larger design and development tasks, however, is minimum viable product.
When designing a system or software service that has many moving parts, it not always possible to deliver “code complete” functionality that meets a particular feature which can be demonstrated to a customer. On the flip side of this, many customers will typically ask the world of the first release of code. Digesting the business requirements of the customer and assessing those against your software and system intuition is critical to ensuring you deliver the smallest amount of functionality to demonstrate capability and ensure your customer is able to provide feedback. Often, even during requirements gathering/solicitation, customers will state what they want, but when it comes to the product being delivered, will completely change their desires.
Thinking lower-level than customer, at an engineering level, think through a large/complex task. For instance, say you wish to develop a portal for the customer, and they want authentication and authorization, an event log, live streaming of new content, subscription models, the works. Assume that your manager has agreed to all of this, and you now have an entire backlog littered with tasks that need to be completed. Work with the manager to understand the complexity of each task, and help guide them to the minimum acceptable tasks that are required to get a functioning “portal” up and running/in front of the customer. Is it critical to have live streaming content in order to demonstrate the look and feel of the site? Is authentication/authorization required if the first time you demonstrate it is based on a complete internal review? There are always tradeoffs, and getting the smallest amount of functionality in front of the requester as fast as possible is key to ensuring efficiency and minimal loss when the customer flip-flops on their request once they see the product.
Limit Context Switching
Broken focus almost always results in delays and unexpected bugs/issues. When working on very difficult tasks, figure out a way to alert those around you that you are not to be interrupted except for the most critical of issues. Context switching is thought to cause an order of magnitude loss in productivity, as it requires the brain to completely re-think new issues (or past ones), slowing progress that was otherwise made. In a software sense, think of it as a stack problem - your brain has many (potentially) complicated pieces of information in it that pertain to the problem at hand, and it took quite a while to fill that stack of information. If you are asked to switch to something different, that stack needs to be completely purged and re-filled with new complicated information related to the new task you are attempting to tackle, which takes time/causes delay and, in many cases, context loss of the previous task if it is ever re-visited.
Don’t think the “please do not disturb” concept is only applicable to peers - this concept should also apply to your manager(s). Establish a working relationship with your manager that helps them understand the cost and context implications of being interrupted or switched to different tasks. If the manager is seasoned and reasonable, they will understand the impact and respect whatever method you agree upon to ensure that context switching is reserved for only the most important of situations. After all - delay on your behalf directly impacts his schedule as well.
Cost of Delay - Cloud (and More Cloud)
There are many costs associated with running a business. Most of these costs are very much specific to raw dollars spend, associated with technology and the staff to support such technology.
However, there are a few intangible costs that may/may not be realized or well-explained but are important to consider in the overall design and operation of software and systems. Consider a scenario where your company has identified a market segment/customer base that absolutely would buy a service/product you offer. However, your services cannot yet reach said market segment. The business then asks a team to prioritize working on the feature in order to capture the market segment.
Think through this scenario - there are many facets to this that are explained both previously as well as down further in this post. Minimum viable product, versatility, managing expectations amongst others are extremely important in how successful you are with capturing the market segment. One intangible cost in this particular scenario is “cost of delay” - that is to say, how many future dollars are lost based on lack of capturing estimated market today. More simply - the longer you take, the less (potential) money you will have made.
Now, how does this relate to the subject of “Cloud”. There are two facets to the cost of delay (there are, in fact, many others, but I will focus on two). The first is the delay due to the overall prioritization of work, software design, delivery patterns, etc. Secondly, costs associated with infrastructure provisioning is a real issue in some companies. In most businesses, there is a technology team responsible for managing the infrastructure of the business. In some companies, this is a larger “Technology Operations” team, while in other, sometimes smaller business, it is in fact an extension of the DevOps Engineer(s) responsibilities to account for this. Either way, it typically takes time (even if a short time) to provision infrastructure related to any activity (software delivery, test/dev environments, etc). If the delay is such that it prevents the software capabilities from getting out the door in time to capture the market segment, that delay should not only be measured, but should overall be considered unacceptable if there is a viable alternative available. In many cases, this is where “Cloud” comes into the picture.
Because of cost of delay issues, many companies are opting to engage with large-scale vendors providing infrastructure as a service (IaaS, such as AWS). However, the cost of these services is quite substantial in cases where companies are attempting to migrate their technologies. This raises a gap/opportunity for Engineers to fill - that is, becoming proficient in cloud-based software development and architectures such that the Engineer can both speed up the delivery timelines for software features as well as reduce costs associated with migrating to the cloud based on optimization. Learning how to operate in the cloud (any cloud, for that matter) makes for a very effective and efficient engineer.
Of course, I would not be responsible if I didn’t mention - operating anything in “the cloud” costs money. If you do not learn how to develop technology for the cloud based on how the target cloud is configured, you are likely to incur significant financial burden as a result, which will appear as though the cloud infrastructure costs more than your on-premise infrastructure. In addition, make sure you do your due diligence in measuring apples to apples when comparing on-premise infrastructure to cloud-based infrastructure - there are operational costs (along with the mentioned cost of delay) that need to be considered in order to achieve an accurate cost metric.
Ask Questions and Challenge Decisions
No good scientist or engineer is without doubt - it is what drives some of the most influential advancements we make as a society. Decisions are, sometimes (in some cases, often times) made in a vacuum without data. As you grow, you will start to develop a “gut” (no, not the kind that causes a scale to go up, although it’s possible you obtain that as well) - deep intuition that something is or is not the way it is supposed to be. This “gut intuition” is what helps experienced Engineers challenge decisions - it is not intended to serve as an elitist/dictator-like experience, but rather, help the Engineer say things like “I think we need to test that hypothesis, it just doesn’t seem correct”, and these types of statements are based on “gut intuition” and are rooted in the experience(s) the Engineer has had in the past.
Do not confuse “gut intuition” with complete guesswork. The intuition comes as a result of the hard work and experiences the Engineer has been through in their lifetime - proven work habits and situations where the Engineer may have been burnt, solved a problem, made a breakthrough, etc. Capture these situations, and leverage the fact that something may not feel right by measuring and proving the intuition correct/incorrect with real data (see section of “Data is King”). Doing so establishes a level of trust in the decision made, as well as the engineers who participate in the exploration.
Manage Expectations
Managing expectations is one area that is close to my heart as an engineer. I cannot count the number of times I have been burnt in the past by this one. In the agile world, complexity estimation of the tasks you will work on are done prior to starting the task. However, as complexity is not an exact science, these estimates are often (especially very early on in peoples’ careers, or when a team is first formed) very inaccurate. In addition, they are often related directly to time of completion based on the fact that the team, manager, product owner, or whoever may not entirely understand how complexity estimates impact schedules.
Knowing that complexity estimates generally should not map directly to hours/days/weeks is an unnerving concept to many managers responsible for product delivery (and their bosses). However, establishing a good communication path throughout the ranks helps with giving the upper management a level of confidence that they understand where things are and the overall cost of delay. If you estimate that a task is very low complexity, but then somewhere down the road realize that you completely under-estimated the work and complexity associated, communicate this. This is NOT to say adjust the existing estimate (as this would fly in the face of most Scrum/Agile methodologies), but failing to communicate the identification of things like this early results in lack of trust in the ability for an engineer to deliver per their estimates. Communication can mean the difference between a customer agreeing to continue an engagement versus completely terminate a contact based on non-performance, and is implicitly important to the core operation of a business.
Mimic Behavior / Identify a Mentor
The internet and businesses are filled with patterns and behavior that have both resulted in success as well as demise of initiatives. Along with the Open Source section comes this explanation of “Don’t re-invent the wheel” wherever possible.
Entire business models have been designed and published for general consumption. Where legally possible, make sure that you are considering “has someone else done this before” prior to starting your own initiative. Even better, ask the question “has someone else done this AND is there a support community around it”. The latter of these is a gold mine from a business perspective because it both saves the business money as well as reduces the risk (i.e. engineer developing customer product X leaves the company and the company has no idea how to support the product/needs to deprecate it or hire specific talent).
Along with mimicking patterns in technology, identify behavior in the workplace and community that appears successful (achieves the intent/objectives). As you grow, it becomes more important to understand how to interact with people and technology in a way that differentiates yourself from your past experiences as more “junior” than your current position. The best way to accomplish this, aside from trying different tactics and failing at/learning from them, is to watch what other successful people are doing and repeat the same behavior. This is obviously a bit specific, as in, you shouldn’t repeat the exact words/actions, but the point is, identify why someone is successful and attempt to reproduce the fundamental concepts that make them successful.
One step further than mimic by observation - identify a mentor. There is almost virtually no position that I foresee myself in that I wouldn’t want to identify a mentor and learn from them to better myself as an engineer. This does not have to be a formal engagement (it can be more of a passive exercise), but I have found that formal engagements where the mentor understands the needs result in more productive conversations and a faster track to maturity in the space. Go into the engagement with a very specific ask/mission of the mentor - let them know how you learn best, what subject areas you’d like to focus on, measures of success, etc. (obviously ensure the mentor is aware of an accepting of taking on this role). Having tangible items for the mentor/asking questions is the most effective way to obtain the information and guidance you are seeking (rather than asking of a mentor and them having to push/having no background or context for how to guide the engagement).
“T-Shaped” Engineer
I once worked for a VP that touted focusing on being more “T-shaped” - that is to say, have general knowledge of a large number of subject areas in your field (horizontal of the “T”), and deep knowledge in a select few areas (vertical of the “T”). While this is a very good thing to strive for, I believe it causes a bit of churn in the workplace if your staff does not completely understand the intent.
Focusing on a more “generalist” nature helps the Engineer become a more versatile resource to a company. If you come into a business only with an expertise in one particular subject area within your field, while some business are specifically hiring for this, many in the Software Engineering field are looking instead for a more broadly-seasoned individual (see the previous concept of “Learn to be Versatile”). Communication of becoming a generalist however, can be misconstrued as “be a jack of all trades, master of none”, which is extremely damaging to the intent of the statement.
“Deep experience” is the vertical portion of the “T”. In almost all cases, expertise in the subject area is vital to the success of the objectives. This is best described via a very trivial example. Suppose that the visual interface for a monitoring system is not updating for several checks that are configured (this could be Icinga, Sensu, whatever - pick your flavor). A generalist may realize that the checks failing are not consistent, and change routinely (it’s not always the same nodes that fail). This would lead the generalist to assume that there is some kind of communication issue. Now, the Network Engineer focuses his efforts on determining if there is a network-related issue in the environment (traditional networking expertise in the “T”). The expertise in this area may allow him to rule out the networking environment. The system engineer starts to investigate the destination where checks are sent prior to being displayed in the UI. They are able to check the system and, based on their fundamental knowledge of how Linux systems handle connections, exposes that there is a file descriptor limit that has been reached and the TCP connections are not clearing fast enough for available sockets to be created, thus resulting in intermittent/unexpected behavior. The systems engineer updates the maximum allowed file descriptors for the process and the intermittent behavior subsides.
Now, with the above (again trivial) example, each engineer played a role in the resolution of the issue. Having only an expert in a single field is not only detrimental to design and issue resolution, but a risk for businesses. However, completely lacking expertise in a subject area is also a risk, in that design and issue resolution requires deep domain knowledge in many cases. The point is, however, that being a more “T”-shaped individual makes you a much easier sell to a business because they can hire you for MANY subject areas while leveraging your core talent/knowledge in the mastered area you’ve achieved. This is far better than attempting to hire subject matter experts in each respective domain, which is likely more costly from a money and risk perspective for a business.
Automate
At the core of the “DevOps” movement is the desire to replicate manual, repeatable tasks with more automated software solutions. This concept, in my opinion, is and should be more broad and applied to any area of an Engineer’s job. Automation can be thought of from two perspectives.
-
Business perspective: Businesses wish to make themselves and their shareholders money. The business perspective can be a bit sharp-edged in that automation implies software-solutions instead of people-solutions. However, this perspective, I believe, is often times miscommunicated by both senior and mid-level managers. The desire to automate does not imply a direct “we wish to fire our staff”. Instead, a business that thrives hires and maintains talent - this means that automation instead frees bandwidth for those talented engineers to focus on other, more interesting ideas to make the business more money. Focusing on this aspect of the business perspective is the best way to achieve participation and realize success.
-
Personal perspective: As an engineer, I’m constantly looking for better ways to organize myself and the technology I own. Having a handle on my technology ecosystem is what enables me to move fast when I need to prototype or deliver. I also hate doing any task more than once - it’s engrained in my work habits. I believe that Engineers in general feel the same way, to the point that they will take an hour to automate something in order to save 2 hours in the potential future. This concept is along the same vein as the business perspective in that it frees capacity to focus on higher-value items, but it also adds the perspective of enabling the engineer to become better at their jobs. The more you focus on something, the faster and more proficient you become - focusing that effort in this area will likely pay dividends in your career, and helps you learn more generally to apply those skills to almost any problem encountered.
Fail Fast
Agile: “the ability to move and adjust quickly”. The same is true when attempting new ideas and concepts/technologies. There is not a responsible manager in the industry who would be satisfied with a new initiative being announced followed by engineers stating that it will take an entire year due to all the facets of the project needing to be considered. When working on new technology or ideas, follow the “MVP” concept as explained previously, but do so also in a manner that helps determine the validity and success of a product short-term. Hardly any technology has been developed quickly and perfect at the same time. Mistakes are made, flaws are encountered, but it is through these that the most successful engineers are able to learn, adapt, and refactor a product into something successful, or recognize the inherent flaws and discard the concept altogether.
Don’t be hesitant to try new things in undiscovered territory - it’s through these types of engagements that some of the most successful technology has come about. Analyze the risk, determine an acceptable success criteria, and measure the outcome of exploratory tasks. Do so in a way that consumes the least amount of time to prove/disprove the success criteria (which should again follow the MVP concept) associated with the task. Telling a manager “we developed this over the last 6 months with all 100 features for our first release but now realize it’s not possible to use it” is generally going to be FAR less acceptable than “we experimented with this over the last 2 weeks based on 4 feature requirements and we’ve determined it will not suit our needs”.
Be Empathetic
People are busy - they have a lot of things to do (in general). When operating in an environment and integrating/working with other teams, be empathetic to their situation. This concept is most applicable in the automation space (operating as a “DevOps” team automating software release processes, operational/infrastructure, or otherwise). While it may seem trivial to automate anything and everything, the human factor cannot be ignored. Working with the operational and engineering staff owning the software and tooling to be updated means you are understanding of their needs and time requirements associated with their normal day-jobs. Pushing hard on your own initiatives at the expense of their time/bandwidth is not likely to produce good results and, in fact, can be inhibitive to the entire engagement.
The point in this line-item is: realize that an hour of your time may not be the equivalent on behalf of the people you are working with, and be satisfied with that expectation. The old saying “You can catch more flies with honey than with vinegar” is very much applicable here, and empathy is the finest form of honey there is.
Listen (Don’t Just Hear)
I cannot count the number of meetings I have been in over the years where I look around after about a half hour and count the heads in the room, multiply that by the average salary I expect everyone to be making, and then sigh deeply at the waste. We all hate meetings - however, they do have their place and they can be an effective tool. There are, however, a few things that need to happen to help make them effective, one of which is that the participants must listen.
The concept of listening is not just applicable in meetings, and the concept of meetings is not just applicable to gatherings of individuals in a closed room. Interactions with other people in the technical space happen all the time. Think of the times you’ve been pulled away from your coding, met with someone else, and thought about that regular expression you were finishing up while having a technical discussion with the individual you were meeting with. As discussed in another section, context switching is in fact dangerous to productivity (so being pulled away is not necessarily the best of scenarios), but even more dangerous is throwing away an opportunity for a productive engagement.
When you are in meetings and/or discussions with someone, no matter how technical the discussion, make sure you are actually listening to what people are saying (comprehending) and not just hearing them. The majority of meetings that I’ve found to be useless are due to one of two reasons (one of which is applicable in this particular discussion) - either the person did not have an agenda and it turned into more of a social engagement, or the participants were not listening so every other question resulted in a “sorry can you repeat that”. The latter of these two is one that the participants can prevent. If you end up in meetings, make the best of them - listen, engage, and walk out of the meeting knowing that either a decision was made or an action item was assigned.
Consider Failures/Security
Flip on the news and you will likely see some kind of story about another business that was hacked or had a failure and lost data. The truth is, it is getting harder and harder to protect against hacking and data breaches. However, I can say with experience that in past positions, I’ve noticed that security is still an afterthought/side-effect of development and system design activities.
Given that there are so many issues related to security and failures, ensure you are considering as many facets of system stability and security as possible. Be overly-cautious in some cases - this could mean the difference between data compromise and a simple audit log reporting that someone had attempted access via username/password 12 million times in 10 minutes. It could also mean the difference between a complete multi-day outage of a website due to a DDoS attack or 10 minutes of an outage due to automatic black-hole policies for requests.
The point is, as engineers, we are responsible for considering the consequences of our actions. We will not always be successful, and things will break/protection systems will be breached. However, placing security and system failure design issues as secondary to the overall design of software and services is an irresponsible activity that will likely be welcomed by hackers and greeted with publication of millions of personal pieces of information on the public internet.
Give Back (Open Source/Other)
I left this category last but, in fact, I think it’s extremely important to the succession of technology and corresponding concepts. Open source software is rampant in the world, as are many projects that fall by the wayside due to lack of support. If you don’t yet have one, think of creating a GitHub account for yourself. If you’ve done something neat/useful, engage the correct channels to receive approval to publish it for a broader audience to consume (legal or otherwise). If you have frustration with a piece of software you downloaded, file a bug ticket, and submit a pull request for the owner of the project to consider/integrate so that others can benefit. It is extremely important to not just re-use implementations that have been done before in order to save time/money, but give back to those projects and the general community so others can benefit in the same way you had and likely still are.
To Take With You
All of the above was a long-winded way for me to explain “be a good Engineer”. I have found repeatedly that effort is the key to progress. Sometimes, filling a gap/demonstrating initiative is the way to make real progress, while other times its doing the hard work to dig in and gather metrics that counts the most. Tailor your engagement based on what you believe the appropriate level of effort and approach are (follow your “gut instinct”, as you start to develop it, and “fail fast” in cases where you were wrong). Give your leadership no reason to ask “why do you think that” by providing proof/details, and give them the comfort of providing you the autonomy you need to do your job (trust that you will deliver/take care of things). At the end of the day, sometimes perception and politics play into it all, but realize that when the hard questions get asked, “data is king”.
Buy me a coffee