Besides the ability to learn and apply technology, it’s been widely shown to truly be successful at software engineering requires an open mindset, supportive habits, and significant discipline. The practice of software development is just as taxing if not more than any other domain and to suggest that we do not need to focus on such things is to suggest other domains simply are all wrong. From sports to cooking to just about any space you can think of some significant emphasis is placed on aspects outside of the skills of that space, and this segment attempts to do the same for software engineering. With these and many other mental tools in place we are on our way to grow from a novice developer to a senior software engineer given enough time and energy.
The most important factor in improving software development is not the tools and techniques used by programmers, but the quality of the programmers themselves.
Other indications fromDeMarco (Peopleware), Fred Brooks, and many others which posit the main issues with software projects are often sociological and not technical. This is backed up by the Prof's personal experience over 20 years.
Economic studies suggest the same
The idea of a high performing developers is often short-handed as a 10x developer as the productivity and output of a highly performing developer may be as much as 10x of an average.
The idea of a 10x performer is not unique to SE, consider any field such people exist (ex: in soccer the idea of a superstar)
Becoming a super start in most professions is a long long journey that involves significant commitment and practice. The idea that the youthful dev is some digital native that immediately exhibits significant competency beyond their peers is a myth more than a reality. Even amongst sports or other professions the wunderkind generally had significant training you simply aren’t aware. TL;DR - the natural born 10x makes a great story but it isn’t realistic.
10x developers often can cause 10x trouble because when coupled with a poor personality they can make a team underperform rather than over perform. Again this type of thing is no different from the moody lead singer of a band that rips it apart of the touchy star player that doesn’t motivate a team.
Obviously we might want to aim to become a 10x developer, and try our best to omit some of the negative aspects.
Step 1 on a 10x generation is starting with the right mindset. There are things we can control (ourselves) and things we can only influence (others, our organization, society, etc.). Postel’s law also known as the robustness principle drives much of how the internet works. Roughly it states be permissive in what you accepts, and strict with what you emit. This seems like a good plan in dealing with what we do (be strict) and what we encounter outside (be permissive)
Intrinsic and Extrinsic motivation is important to distinguish.
An external motivator might be a paycheck, a super nice car you want, a new job title, etc.
An internal motivator might be the enjoyment you have when you solve a puzzle, how it is interesting to explore a new technology, or finish a project.
It is my general view that external motivators are harder for you to control (think Postel’s Law) while internal one’s you can. For a long career you probably need a bit of both. However, do not misinterpret as a value judgement. I am not saying one is better than the other, just that you likely need a bit of both. Your personal balance will likely not match anyone else.
Finally to stick with something like SE long enough to approach a mastery level you need to separate attitude from ability. Likely you will always be learning and trying to get good at something new as your ability at a new skill won’t grow out of nothing. You need to have a positive growth oriented attitude first and put in the effort to grow your skills.
Generally I often will say you can train a skill, it is tough to train an attitude. A person needs to adopt the attitude first.
Following along the previous point we need to put in appropriate practice so we mastery a skill. We should assume that we will unlikely get “perfect” at something with practice, but quite likely we will get better at it with appropriate focused and consistent practice.
This relates later to our dev habits where we break out some time to practice a skill rather than just immediately expect to be good at it.
Practicing skills isn’t just about things like typing, learning a coding syntax, IDE macros, etc. but also can cover so called soft-skills.
I rename this non-tech skills rather than soft as that implies some hierarchy of importance. It turns out both types of skills (tech and non-tech) are important.
Examples of practicing non-tech skills might be trying to speak up more in a meeting, writing for fun such as blogging, working on an organizational schedule for your days, developing habits, etc.
Good “players” can still succeed with bad gear and bad players don’t instantly become good ones with good gear, but it does help.
As we play the game of Software Engineering it is important to consider our gear. We really must first focus on our input/output as that is how we get our thoughts into code. This suggests keyboards, screen, and mice are pretty important.
Generally my attitude is that we try to get the best gear we can that we are comfortable with. Be careful with replacing gear all the time thinking it will make you better, but invest in yourself not just with your habits but with your devices as appropriate.
Industry Tip / Observation - good orgs don’t skimp on equipment. It is an easy way to get higher performance out of devs to make sure they have what they prefer. If necessary, bring your own gear and advocate for more quality “kit” so to speak. Note this idea is not unique to me at all Spolksey and others have talked about this for well over 20 years and most larger tech companies like Microsoft have traditionally being supportive of devs in this area.
Constant sprinting - you can’t expect to be optimal all the time and perform at maximum effort
Rest and efficiency - like the previous statement you need rest to be efficient. You might be able to hack energy for a while with Redbull, but ultimately a few hours with appropriate rest often beats 10 hrs with little rest
Flow State - when you get in your optimal state of work it is almost a feeling of natural flow. It can be very difficult to get into this state without appropriate rest and minimal distractions/interruptions. Guard your ability to get into this mode as it is key to quality software development
Multitasking and Distractions - an enemy of flow state is distraction. From an interruption or self created distractions it is really impossible to be great at your dev tasks if a bunch of other things are stealing your attention cycles. The thought we can multitask and that is efficiency is also a massive fallacy many subscribe to. The science shows you can’t really do it at least not well so try to avoid it if you can. We see this type of idea manifesting all over software engineering for example the idea of keeping your WIP (work in progress) low, to work on a task until done, etc. are all supportive of this base idea.
Rhythms - understand your own rhythms and accept them. If you aren’t a morning person don’t code then for example. Admit when you are tired and do less stressful tasks, basically admit to our “daily seasons” and act appropriately.
Avoid Yak Shaving and the appearance of busyness - many in our industry are very busy doing meta work. Traditionally in software engineering we often talk about the type of work with think is necessary or have to do before real work as “yak shaving”. Try to limit falling the track of appearing to work. You’ll see many examples with Github punchcard faking, constant social media proclamations, configuration or cleaning tasks, and more once you start looking for performative hustle.
Confusing Confidence and Competence - be careful with faking it until you make it
Impostor Syndrome (aka Comparisons and Self Esteem) - like item above we do know when we are faking and if we see others doing we can deeply harm our self-value. The idea we are an impostor is a dangerous thing and it has been significantly amplified by a social media powered comparison culture. Remember we all don’t know things and experts were certainly novices at one point or another
Absolutism (aka Black and White or Binary Thinking) - when it comes to humans which includes us we need to be very careful with absolutist thinking which is common amongst engineers. Example is X is the best, Y is the worst. The truth is that thing being best or worst is pretty subjective and given condition often “it depends.” Applying strict absolute thinking to our behaviors can be quite toxic
You != Your Code - it is important to have pride in our work or code. However, taken to an extreme we may personalize our work too much. The truth is that even the most gifted developer will write some bad code. Try to avoid tying in your self value solely with your work or code. Commonly it used to be a common thought in engineering to be dispassionate about things so you can just allow something. In other words, we aren’t so worried about what we did as it is external to us. Unfortunately that is less broadly held amongst developers today.
Selfish and Selfless Devs - selfish devs often are quite worried about what they think and how they feel. This often leads to making decisions that may harm others including end users. Likely that is not one’s intent, but we should be a bit more selfless and understand who we do things before.
A developer with too much breadth but no depth isn’t great except in overview situations. Such folks often do better as project coordinators or in small orgs where we can afford to do less quality with less people. A developer with too much depth but lacking breadth often misses important external effects or opportunities. These developers also are more valuable in large groups as specialists, but may run the risk of being eliminated if the speciality falls out of favor. The best devs tend to be a “balanced T” and have breadth and depth within reason.
Good dev habits vary, but start simple like showing up and being present. For example, if you go to a meeting, be present in the meeting not checking your email or zoning out. Habits will vary, but I have found things like small consistent progress over time as a key one. Basically try to aim to do a few steps on something important to you as often as possible without fail to get big huge gains. What is important to you I can’t say, but it might be anything from learning to use your IDE better, to understand many algorithms, etc.
Many developers suffer from a need to be a perfectionist. This is a bit of a variation of black and white or “binary” thinking where we either perfect or a failure. The truth is we are often all a bit good and a bit bad at what we are doing. Our aim should be to allow ourselves to fail a bit and just work at things with less judgement. We must reserve judgement as growth only comes from when we push ourselves and that will result at times in failure. If we can recast a failure by seeing what it taught us and keep the effects of the stumble minimal we can effectively grow
A number of tweets and quotes were provided to show various tips on getting on the path to a senior engineer. Interestingly many of these tips have more to do with skills beyond tech. There was a bit of sameness to the tips, but the truth is the path is long and winding. You’ll need to be patient and know that how long it takes and what you need to work on will vary, but stick with it long enough you’ll get there! I’ll jokingly (not really) say that you need to “Train for a marathon, not a sprint” in our field.
It’s been long held that the biggest factor for improving the quality of software and the success of a software project are the developers themselves. So called 10x developers or more realistically high performing developers do exist and can significantly help or hurt software teams. Unfortunately building such developers isn’t some simple algorithmic process. A key step is adjusting our mindset to growing, understanding our motivations, working at our habits, accepting that we may need much more than technical skills, and be willing to stumble along the way. While much of this topic might be new to you in your CS program little of it is really that new. In some cases I just recast materials, in other cases I took SE observations commonly held. Regardless of how/where I got the ideas of the segment the quotes and books significantly back up the importance of these tips so ignoring them in favor of some more predictable tech thought may be quite impactful on your career growth.
Again many of these ideas seem to involve a value judgement upon developers. We produce product of the mind and often to do it well we need heavy concentration and flow. Many of the ideas pushed at us unfortunately are counter to our actual success. A grind or hustle culture epitomized by the idea of 996 or the start-up culture is a near gurnatee of burn-out. Like an athlete over training, getting injured, or just not reaping the benefits of effort so to do we find individual devs defying human realities.
It truly makes no sense to suggest that we don’t need to listen to our body, to not address our attitudes, to overly push or aggressively pace ourselves, and to have a wholy unrealistic expectation of our ability and growth. If we were athletes we’d train constantly, assume we would never lose, if we lost blame others, attempt to sprint a marathon and somehow take our growth curve to believe we could run a 2 minute mile. Even worse we’d likely believe Nike it they claimed their shoes could help us run that 2 minute mile.
The silly comparison given is just one technique of the segment to knock us out of an unhealthy views that suggest everything is first mover and winner take all at any expense. The truth is that software already has more than 50 years of history and such thoughts have more often lead to burnout and failure in the long run at best the hustle culture offers for most a short term win giving way to a long term loss. We sadly build around the few outcomes assume that we will somehow rise above. Rather than fall for the fairy tale, maybe we should enjoy a process that allows to see that we are not deeply different than other humans and if we can accept that we will likely be better devs and work better with others.
Example Test Questions
Explain the idea of the 10x developer in Software Engineering.
How does one typically become a 10x developer?
Discuss the pros and cons of a 10x developer.
Some people deeply wish that tools and technology will solve developer productivity issues. Data and history doesn’t seem to suggest that is a good bet. If that is the case why do you think people keep pushing the tool over people idea?
Provide a modern example of this thinking and at least one thought that may make holding out for a big tool/tech win unlikely.
What does it mean to be a “T” Shaped engineer? Provide a short example of how a T shaped engineer might save a project or team.
What is impostor syndrome?
Why do you think developers get impostor syndrome so commonly?
If failure is required to learn things describe how to approach failure in a safe way as a learning dev. For maximum consideration make your answer personal or related to what you experienced on your team or an internship.
At times it feels like industry is moving so fast that anything you learn in school or even on a job is out of date before you even master it. Figuring out coping mechanisms to address the whirlwind of change is a key skill for a software engineer these days. Describe how you might approach this for your growth beyond this course. Hint: Think about dividing your learning efforts and time % wise and topic wise.
SEs are smart people and like most people we do things for real reasons. However, as we have observed in this segment and across the industry there are many misconceptions and beliefs that seem somewhat troubling as we stop and ponder them. The Prof contends that some of our beliefs and misconceptions are likely driven by numerous forces many potentially more system based including economics, social, regulatory, custom, convention, and more. See if you can think of an example to support his thoughts. Avoid just saying someone is ignorant. If ignorance is a key component explain how that came to pass from a system’s point of view.