10 software engineering lessons that changed my life

I've been in the software engineering industry for almost two decades now during this time I've worked for companies of all shapes and sizes and even created a few of my own startups along the way I've learned some very valuable lessons from working with incredibly smart colleagues as advice from various mentors I've had and just through my own failures these lessons have played a huge role in the success I've had as a software engineer and as a entrepreneur so in this video I thought I would pick 10 of my most valuable lessons I've learned in my career and share them with you and if you stay till the end I also have a bonus lesson that ties everything together and will set you apart from the rest of the crowd all right let's get started hi folks my name is utav if you're new here I'm a software engineer based in Seattle I have about 20 years of experience in the industry where I've held diverse software engineering roles and created a few Tech startups and I'm currently at Microsoft if you're new to this channel my goal here is to help you get the best out of your career by mentoring you around five key pillars technical skills engineering efficiency mindset entrepreneurship and Financial Freedom so if that sounds interesting please consider subscribing and follow me at engineering with UTA for behind the scenes and monthly q&as it doesn't really click until you sit back and think about it but software engineering is really all about making choices particularly good choices from the day you decide to pursue a career in software engineering till the day you officially retire you're essentially comparing a bunch of tradeoffs and picking the choice that gives you the most favorable outcome there is really no wrong or no right the answer is as you've probably seen in many memes already it depends and this is where most new software engineers get it wrong they want to build the most optimal thing the fastest thing the most accurate thing in the real world though you will quickly find yourself having to choose between the things like optimal fastest or most accurate there are always compromises the fastest thing isn't the most accurate the most accurate thing isn't the fastest and sometimes if you try to do both fast and accurate it may not be scalable when you understand that there is no such thing as a perfect design you will start thinking about the trade-offs and the compromises you will need to make in order to prioritize the areas that matter more for your product that you're trying to build and the better you get at making those choices the faster you'll move up your software engineering career coding is only a small part of software engineering and dare I say coding is actually the easiest part of software engineering things that I mentioned earlier in the previous lesson understanding tradeoffs and making the better choices are much harder things to do but this is a common trait I often see in junior Engineers their enthusiasm to write code and the belief that jumping into code to get a head start shows initiative I was the same but the truth is that jumping to code code the first thing that comes to your mind shows naivity and lack of experience so I encourage you to shift your mindset around code and delay that urge as much as possible instead think about how your product or feature will be used think about the trade-offs we discussed in the previous lesson uh pretend to be your own customer and imagine using the final product if you have the option or the skill mock up the whole thing and get feedback on the workflows before you even write a single line of code as you do this exercise over and over again you will realize that the initial design you were jumping into code will change multiple times over you'll realize that you can keep your features much simpler than you had initially thought you'll see the areas that naturally have repetitions that you can extract out to remove redundant code workflows this will also make your actual coding much simpler and easier and to that end here are three simple principles I encourage you to keep in mind before you start coding anything yagi you aren't going to need it if you're not 100% sure something has a critical use case for a customer don't Implement Drive don't repeat yourself if any code flow or module repeats itself more than twice extract it out to remove redundant code blocks kiss keep it stupid simple no one is going to be impressed by a cool short hand or a fancy oneliner that requires five lines of comments to properly understand always keep it simple and straightforward this lesson Builds on the previous two treat every project you work on as a mini startup that you're creating it really does not matter how great your software is if no one is using it so don't obsess about building things right before you obsess about building the right thing think of the elon's gates and jobs of this world there were E before Tesla there were operating systems before windows and there were phones before the iPhone but those prior products never reached the same Heights because they weren't the right products for the right time see it is really difficult to find people that have a knack for building the right things but once you figure that out and you know what the right thing is to build build it is relatively simpler effort so start thinking like an entrepreneur before you put your software engineering hat if I got a dollar for every time I said which programming language you learn does not matter I would probably be rich by now yes there are modern languages and there are older languages but understanding any one language thoroughly is far more important than your choice between a cool and a supposedly uncool language a programming language is just a tool if you don't know how to use it properly it does not matter how good the tool is if I was interviewing for a position for my company I would hire a phenomenal programmer that only has worked on one programming language that isn't even used in my company over hiring someone else that has basic understanding of five different cooler programming languages because I know that the person that understands the concepts thoroughly will be able to pick up any new language relatively easy and the choice of picking a programming stack is also often influen inuenced by many other things outside just the performance of the language you rarely ever get the luxury to pick the best stack purely on its Merit for example let's say you have a highly concurrent workflow in your services and you're considering switching to go but 90% of your workflow is familiar with know well you're out of luck because replacing your entire headcount pool to optimize for a programming language is not only unfeasible it is downright foolish here's an analogy think of yourself as a driver if you're just learning to drive it doesn't matter if I give you a Mazda Miata or a 911 GT3 RS you will not be setting lap records on any track your top priority is to become a better driver and to obsess about how to learn to drive not the vehicle you're driving because a better driver will almost always beat you with a lesser vehicle this is called the duct test a form of inductive reasoning and it applies very well to a lot of software engineering scenarios the core idea here is to mock everything and anything to make your way forward say you need user feedback before you even write code marck the entire project with deterministic steps and see what the user thinks if it works like the final product and looks like the final product it must be the final product right or if you are blocked on some other team to release a library to progress your own code create a mark library with the expected Behavior this is called contract driven development if it acts like the library responds like the library it must be that library right or maybe you have too much data flowing into into a relational table and deleting takes as long as inserting well create partitions to split the data and swap out the UN needed partition into a table essentially making SQL think that the chunk of data in the partition is actually in table then truncating a table is a matter of a split second if it acts like a table has apis of a table it must be a table right I hope you get the idea mock everything and anything that blocks your progress I would even go as far to say that it's a more professional and Technical version of fake it till you make it heck during one of my startups I had a product pitch with our VC and we had a few the issues come up last moment so we mocked up some of the parts that were problematic the bugs were fixed later and we ended up getting funding that we were seeking it may sound imprudent but mocking is a critical tool that allows you to iterate over the code feedback and improve Loop way faster so take mocking not just as a process to help unit tests or just a cool side effect of polymorphism think of it as a critical tool to help you make progress remember if it quacks like a duck and like a duck it must be a [Music] duck this is probably one of the most important lessons I've learned through my various startup Ventures unless you have a lot of your own Capital to invest into your own company taking an idea and pitching it to a number of VCS and getting funding for it is very gruelling it mentally and physically breaks you down and that is just the start getting funded has nothing to do with whether you're successful or not and during the process a lot of key players ERS have ideas and opinions about the product that you're trying to build some of that is good feedback and helps pivot the concept into the better Direction While others aren't and this is where as a Founder it really helps you to have a mental fortitude to be able to be stubborn about your vision but have the openness to take critical feedback and be flexible to change the details the funny thing about this is that it is kind of similar to a principle in software engineering that you all are probably familiar with it is the O in the solid principles or the open en closed principle which states that software entities such as classes modules and functions should be open for extension but closed for modification this helps greatly with maintainability scalability and reusability and similarly being stubborn with your vision but flexible with details helps you maintain the core identity of your idea but get feedback and adapt and evolve as needed quick note if you're looking for a platform to help you expand your software engineering skill set whether that's distributed systems or machine learning or just brushing up your coding for interview prep I highly recommend you check out educated this video is not sponsored by them or anything I'm simply recommending them to you because I've been personally using them for over 4 years now and I genuinely believe that they're one of the best software engineering education platforms out there and no wonder they're trusted by millions of software Engineers from Top tech companies like Netflix meta Apple Microsoft Google and Amazon the thing I love most about educative is that their content is precise relevant with emerging Trends and of top quality so I always feel like I get maximum value out of my time a lot lot of you message me asking about how I keep my engineering knowledge up to date aside from books well there you go I use educative check them out and see what you think and if you like what you see you can use educative.io engineering with utsav to get 10% off your annual subscription all right back to the video one of the most underrated things that is a major contributor to your career growth is how much you help others around you grow if you can help others grow you will be climbing up the promotion ladder very quickly but even on a personal note teaching others reinforces the skill you're trying to learn I learned these lessons over the course of tens of years and sometimes in the thick of deadlines and life happenings even I forget to follow some of these but when I have to Mentor someone or even make this video I have to reflect on those lessons and do some critical thinking around the things that I'm sharing which reinforces them in my own mind and maybe some of them will stick on to you guys and help you out in your career it's really a way win and I think everybody should aspire to be a mentor to someone else it urges you to also set high standards for yourself being a rockstar coder will only take you so far unless you are among the top 0.011% of software Engineers that are destined to travel the individual contributor route all the way through to a technical fellow you have to at some point pull out your interpersonal skills you will need to lead teams you will need to influence or sway decisions to certain directions and you will even need to inspire when it's not all smooth sailing in fact the more experience you get the less you'll be coding you'll be doing a lot of the other things that I've already mentioned in this video like identifying the trade-offs and pitfalls of a design thinking from the perspective of your customers ensuring that your team is making consistent progress teaching and mentoring orders and so on and so forth so don't lock yourself in a dark room and only code for hours on end socialize build your interpersonal skills understand people build up your emotional intelligence when your pure coding horsepower ends these things will take you a long long way now if technical abilities one/ third of the career equation and interpersonal skill is the other 33% then your manager or your Mentor is the final third even if you have the technical skills and the non-technical skills you can still get stuck in your career without the right manager or the right Mentor we don't have a choice with managers sometimes because they're sort of given to us and switching may not always be possible but mentors you can find on your own accord and it surprises me how many people have no mentors in their life I've said this in many of my previous videos already but great managers and mentors have very distinctive traits that you should be in the lookout for for example they want to listen to you more than they want to talk they want to create a safe space for you to go and talk about your struggles and frustrations they always give you credit for your work and celebrate your successes they Inspire motivate and lead by example they also give you the freedom to choose how you work and when you work their relationships are based on on trust they do not micromanage they give actionable feedback to help you improve instead of criticizing your work they also support your technical growth and your personal growth but above all they are grounded and human they treat you with empathy and respect and not as yet another headcount in the system so watch out for these qualities and if you get lucky enough to work with a great manager or a mentor stick with them throughout your career you will write a lot of documents Drive many meetings make multiple product pitches and while you do these things remember to never underestimate anyone's intelligence but also never overestimate their prior knowledge always assume that people are intelligent enough to understand the core concept of what you're talking about avoid explaining the basics for example if you're using a choreography pattern for your project don't explain how publishing and subscribing Works re explaining trivial things can be patronizing respect people's times however this is a fine balancing app sometimes maybe you need to explain the basic concept at that point you may have to consider if you have the Right audience should people that don't understand message cues be deciding if a choreography pattern is the right architecture for your project probably not on the other end always assume that even the most intelligent people do not have prior knowledge of your exact domain or product so keep it simple explain the context and give enough background information for the same example we're using with choreography pattern explain why you went with that in instead of say an orchestrator pattern or whatever else the contextual decision- making process was but avoid unnecessarily technical jargon and espcially acronyms because those inhibit communication there's an email that Elon sent to everyone in Tesla in 2018 where he clearly asks everyone not to use acronyms for the exact same reason the gist of it is don't overe explain but give relevant context and keep it very simple concise and straight to the point that is the key to driving great meetings and product pitches look you may someday go on to do great things with your passion reach very high position in your company build something that millions of people use write books or become a very respected voice in your space and that would be a very fulfilling career but I will also mention something that very few others talk about one of the main objectives of your career is to provide for yourself and your family and for that you need to secure your finances psychological fulfillment alone isn't going to pay your bills I see so many software Engineers that make very respectable salaries essentially live paycheck to paycheck because they didn't go the extra mile to educate themselves about Financial Security Independence and freedom this is especially important in the current market where layoffs are common place it doesn't matter if you make a million dollars a year if you live like a millionaire and don't take the necessary steps to secure your financial future you will always be tied to your paycheck being tied to your paycheck will severely limit your ability to take chances or calculated risk which for a software engineer or especially an entrepreneur is pretty much game over so make sure you put the same amount of effort on securing your finances as you do in improving your technical skills or your general career a combination of this will give you the skills and the freedom necessary to capitalize on opportunities when they come knocking at your [Music] doorstep okay the final bonus lesson that wraps everything together is to have a bias for Action having a bias for Action means that you have the tendency to favor action over inaction I can give you 20 more lessons here but it will mean nothing if you're going to watch it forget it and move on to the next video on your playlist results happen only when you take actions and if you look at each of these lessons each of them urges you to act on something understand the trade-offs and make hard choices instead of being stuck in analysis paralysis iterate through the design instead of jumping into code think from the perspective of your customer pick a programming language any programming language and become great at it don't stay block mock things and keep progressing teach and help others grow be steadfast in Your Vision but always welcome feedback develop interpersonal skills and Leadership skills find a good manager and a great mentor don't underestimate or overestimate others think long and hard about how you spend your money none of this is confusing none of this is complicated so have a bias for Action don't overthink or delay your decisions and work towards improving things right away always remember that doing something with educated guesses or a calculated risk is always better than doing nothing a self-starter with a proactive and entrepreneurial mindset embodies bias for Action it is their mode of operation or mod of operandi it is what makes them successful and sets them apart from 99% of the rest if you feel like you're stuck in your career and want to get promoted faster check out this video where I give you pointers on why you were not growing as a software engineer and since I mentioned how important Financial Security is in the context of your overall career check out this other video where I explain everything you need to know about finance and investing as a software engineer if this video is useful please hit the like button and let me know anything else you have in your mind in the comments below subscribe for more videos aimed at helping you grow your career holistically I'll see you in the next one cheers [Music]

Channel: Engineering with Utsav

Views: 33,604

Keywords: software engineering, coding, developer, software engineer, programming, productivity, engineeringefficiency, entrepreneurship, leadership

Id: Ucu446OwmOE

Length: 18min 54sec (1134 seconds)

Published: Fri Apr 19 2024