Neville Lewis

🚀 10 Signs You're a 10x Engineer (and don't even know it!) 🧑‍💻 1. You've googled "how to exit vim" more times than you'd like to admit. 2. Your commit messages are works of art. Sometimes they even rhyme. 3. You've fixed a critical bug by adding a single semicolon. 4. Your code comments are a perfect blend of humor and despair. 5. You've mastered the art of looking busy while waiting for your code to compile. 6. Your rubber duck has seen things no duck should ever see. 7. You can explain technical concepts using only memes. 8. Your coffee intake directly correlates with your git commits. 9. You've had heated debates about tabs vs. spaces. 10. You've written "it works on my machine" so many times, you're considering getting it tattooed. Bonus: You're reading this and nodding vigorously! 😄

82

17 Comments

Job-seeking Dev or Engineering Manager? Here is how to nail the coding exams (and a bit of cheating).💪 First, get it out of your head that you will find a job before the end of the year. Yeah, the end of the year! 2024 is basically done because almost no one is going to be hiring during the holidays for obvious reasons. Second, if you haven't interviewed in the last 2 years you have a LOT of work to do because every #job thinks they are a #FAANG now. Third, at least you have time NOW to prep. Here is the usual breakdown of #interviews now: 1. Recruiter Screen 2. Coding #Technical (generic) - even you Managers! 3. Project Overview (technical) 4. Behavioral (manager) -- Dev: 5. Coding Exam 2 (platform) Manager: 5. Management experience -- 6. Product and Design (product/design team members) 7. Architecture / System Design There might be more for higher level positions with more senior members of staff around Leadership, but 7 "rounds" is normal for non-exec level. Let's jump into the first bar, PASSING THE FIRST TECHNICAL! 👩‍💻 Grind Your Gears as it is time to #LeetCode 😮‍💨 1. Make your plan on Grind75 https://lnkd.in/gZeZrTiK and focus on the kinds of questions that will be asked for your level. *Protip: Most every job will do a Leetcode Medium for this and 30min to get it done while talking to someone. Managers might get a Leetcode easy and Staff+ a Medium-Hard. Only Google really seems to enjoy doing Leetcode Hard in the interview cycle for some reason. 🤷‍♀️ 2. Get the Answer ahead of time #Glassdoor, #Blind, and other Company review sites OFTEN have areas where people post what their questions were IN THE INTERVIEW and what level they were interviewing for. Even if they aren't giving the same question, you can find out what they might ask and how to solve similar problems ahead of time. 3. They left it in the Open #Github and #Bitbucket are great, especially when companies use them to host the their SAMPLE codebase for the interview. Reddit and others do this, some just list it under a different workgroup so it isn't as obvious but still shows up in a keyword search. This way you can know what the question is & how to solve it or what they will dump on you in the interview. 4. Pick your Formula I'm a #Kotlin Dev primarily though I know a lot of languages and I found the perfect combo. Data Class + Collection Operators. Seriously, there is almost nothing in a coding exam you cannot solve with these two things. Knowing Collection Operators like `filter` and `map` as well as more advanced indexing and things like `forEach` shows not just language knowledge, but code that ultimately looks more precise and professional with generally faster execution than similar iterator `for` loops. Figure out what consistently reliable method you can use to get an answer on a page that works and allows you to iterate to better. YOU WOULD NOT BELIEVE HOW MANY PEOPLE NEVER EXECUTE CODE OR GET A WORKING SOLUTION! Win 🏆

27

4 Comments

Can someone explain to me how to get "more experience"? I have 16 years of full stack software engineering experience, mostly in C# .Net 4.2 through 8, including .Net Core 2.x & 3.x, along with WCF, WPF, Winforms, Razor/Blazor, HTML, CSS, and JavaScript, with Entity Framework, Dapper, Linq, SQL Server, MySQL, SQLite, Oracle, NoSql, and other databases. And a few of those years include a combination of Java, PHP, and C/C++. I've also used MarkDown, PowerShell, MVC framework, Swashbuckle/Swagger, Newtonsoft, JSON .Net, TopShelf, and a variety of testing frameworks. But apparently that's not enough. In the past 3 years alone, I've learned ReactJS, TypeScript, Xamarin, XAML, Maui, NodeJS, Terraform, AWS, and Azure, and I'm currently learning Angular, but that doesn't cover the 3-5 years of experience jobs want. I've learned some of these skills through jobs, but also some on my own. Except that as often as companies want us to learn these skills outside of work, they only count professional experience when it comes to hiring. My last interview said I needed more experience, as if the previously mentioned 16 years wasn't enough, and neither was the 15 years of computer repair and networking before that, which their interview questions also covered. So if no one is willing to hire because people don't already have experience, how are we supposed to get the experience? And don't say "open source projects", because they don't count as professional experience. Or do I have to take a 50% pay cut to take an "entry level" job that still requires 3-5 years of experience that I somehow still don't have? People are quick to say that "no one wants to work anymore" when they can't get hired, but they never seem to think "businesses aren't willing to teach anymore" when they refuse to hire people. Why? Is it that we are so conditioned to think that it's always the individuals fault for not living up to expectations, instead of the businesses fault for setting unrealistic and ever changing expectations? So, I ask again, how can I get the required experience when employers refuse to hire unless I already have experience?

2

How to make offices less distracting (and more productive): * Make smaller floor sections w less seats * Sight / Sound blockers on desks * Provide enough meeting rooms This removes most sources of unwanted distractions.

2

"Curiosity over tenure" -- use quality telemetry in your traces to make debugging accessible. Empower curious folks to debug, not just the most tenured person on the team/company. Metrics are great... they're cheap, enable high data retention, but they're coarse... too coarse to understand what's happening in your system. If you're solely reliant on metrics, you'll need lots of intuition and tenure to understand what's going on in the system. "Oh... it's the cache" says the hero on the team peering over a graph, and doing some inaccessible pattern matching. It looks cool, but it's not scalable. Adding lots of telemetry to your traces ensures anyone with a curious mind can understand what's going on in your system.

3

For folks out there that have corporate OSS initiatives which involve GitHub, it is probably good to understand the nuance of how public and private repository forks interact: https://lnkd.in/eU_YvCSw #git #github #opensource #oss #corporateoss

4

Everyone thinks this is an exaggeration but there are so many software engineers, not just at FAANG, who I know personally who literally make ~2 code changes a month, few emails, few meetings, remote work, < 5 hours/ week, for ~$200-300k. Here are some of those companies: Oracle Salesforce Cisco Workday SAP IBM VMware Intuit Autodesk Veeva Box Citrix Adobe The “quiet quitting” playbook is well known: - “in a meeting” on slack - scheduled slack, email, code at late hours - private calendar with blocks - mouse jiggler for always online - “this will take 2 weeks” (1 day) - “oh, the spec wasn’t clear” - many small refactors - “build is having issues” - blocked by another team - will take time bcuz <obscure tech reason> like “race condition” - “can you create a jira for that?” And no, AI is not writing their code. Most of these people are chilling so hard they have no idea what AI can do. Most people in tech were never surprised that Elon could lay off 80% of Twitter, you can lay off 80% of most of these companies ~ Deedy Das (via the 𝕏 platform) I've been reading Naval Ravikant's book wherein he discusses how the goal is to get paid not for your effort, but for your decision. Ravikant highlights how even a 10% higher success rate can make a difference in the millions and therefore, the person who is able to bring in that 10% extra success is likely to get paid top dollar. These companies don't want their employees to be on the grind. They want them to come in clutch when it matters most. — Amazing! Meanwhile, getting hired is a nightmare right now for people wanting to work. Unless they are working in a niche area and have domain level expertise (that took many years to develop), they are most likely one major decision away to be axed (their department / team than themselves).

1

4 Things You Should Put in Your Daily Dev Log To harvest meaningful patterns from your dev log, you’ll need to capture the same things daily. I’ve been engineering software for 25 years, and I’ll share what I’ve routinely kept in mine. Your context is different, so your list will be also. Just make sure you capture the same things daily. Use this list as a skeleton to start from. It’s easier when you aren’t starting from a blank page! Pull Requests I keep track of every PR I submit, approve, or merge. Almost any work product I deliver or review flows through Git. My lists of PRs serve as a personal task-level kanban board of work in progress that I am connected to. These help me easily reconstruct a story of what I’ve done throughout the week. Personal Interactions I make note of every personal interaction I have, scheduled or otherwise. In addition to these notes, I keep a page for each person, and I link to that page from my daily notes. As I note patterns of interaction with a person, I’ll describe those patterns on their page. Over time I build a library of every person I’ve collaborated with and what we worked on together. Project Actions I keep a running narrative of the things I’m working on. I keep a section for each thing I’m working on. These might be at the product or story level - it just depends. Each time I hit a stopping point or interruption, I make a note of what I’ve been doing and what I plan to do next. Guess what I use to inform my daily standup updates? Perplexing Puzzles I make a note of everything that surprises me. These could be strange program behaviors, blockers, production issues - anything unexpected. As I review these periodically, I ask myself how I can use what I’ve learned to improve my mental models. Hopefully this list helps you get past the starting line. Do this faithfully for several months and see where it takes you!

8

8 Comments

Struggling with efficiently managing your software engineers for your company? Wish you had a way to retain your best engineers and get your projects delivered on time? Let’s chat. I’ve built and run several large teams with the highest retention and efficiency in my divisions.

9

When I started my career I started with pure business critical Linux Infrastructure. I have seen downtime due to hard-disk failure, and have seen the never ending struggle due to bare boot or kernel issues . Eventually when everything migrated to the cloud I was surprised to see zero down time migration or even recovering a vm from snapshots in no time!! That simple , that easy!! I kept upskilling just to realise devops is nothing but connecting every dot of SDLC with automation by increasing the layer of abstraction for the sake of increasing throughput. I could understand it better because of my "Old On Prem bare metal" experience. Eventually the toolchain, the frameworks everything else demands only one thing "Delivery of Secure Quality Software at rapid speed". The more you connect dots the more creative yiu become!! So, dev + QA + Sec + Ops + Everything else can be connected through the dots plotted in a single plane (or should I say platform!! ). Just one click and bang !! The SDLC engine starts running. So yes, Platform Engineering is the next big thing. And no you won't be obsolete! upskilling a bit would make you a great asset of setting up (architecting) the perfect platform for "Delivery of Secure Quality Software at rapid speed" (whatever the way industry wants. )

18

There’s something for everyone in web development in here:

8

1 Comment

sequence diagrams are a personal favorite and mermaid makes them easy to keep up to date and embed in markdown

7

2 Comments

Here's something I read and re-read: https://lnkd.in/gq6n-N2Z As a Principal Engineer, my role extends beyond just creating and coding. The use of management techniques is pivotal, acting as a force multiplier. These techniques, combined with soft skills, enable me to guide my colleagues in maximizing their outputs and tackling strategic challenges that shape our roadmap 3 to 5 years out (or longer, in some cases). It's our leadership that makes a difference. In my experience, a significant part of being an effective Principal Engineer is cultivating solid professional relationships with folks all over the organizational chart. This allows me to help the Engineering Team achieve the best outcomes with the least amount of friction, a key aspect of our success.

7

2 Comments

With DORA metrics, the precision matters more as the metrics matter less. It doesn't matter if the number lacks precision when it takes 30 days to get a change into production. You could be +/- 5 days, and you'd still be deploying "monthly". When you reduce this to less than a day and start measuring in hours, the lack of precision would mean the noise disguises the signal. However, you don't need to fix this as your constraint has likely moved elsewhere. #DevOps #Metrics

19

3 Comments

Hire for the person you need 3-6 months after a person fills the role. Or, better yet, the next role. You can teach a specific tool or how you code within a specific programming language. So don't hire for that unless the job is BUILT around that tool. The things you're really looking for propel the person into the next role or into doing more in the current role - and faster. When I see what you've got your applicant tracking systems screening for...it can really make me shake my head. I come from the days before it was all online. From when it was both easier as simpler. I used to place ads in a thing called a newspaper. Yes, really. So the advice comes from then as well. Make every word count on your job description. Put your specifics in the preferred qualifications. Know what you truly care about, and commit to keeping your tech job descriptions relevant to the work and a career path. You'll have to revisit and revise tech job descriptions more frequently than other types of roles. Today's advice - do not filter out people with 10+ years of technical experience who lack a technical degree. Need a hand hiring tech people? I can help.

49

9 Comments

5 years in software and dreaming of a $400K+ salary? It's not as far off as you think. Over the last 3 years, I've helped 53 engineers skyrocket their careers and bank accounts. Like them, you might be thinking, "I need at least 15 years for that." Let's set the record straight: Feeling inadequate because of a timeline is an illusion. You can accelerate your career by focusing on 5 key areas: 1. Impact: Deliver results that showcase your value and potential. 2. Communication: Explain complex technical concepts in simple terms. 3. Mentorship: Seek guidance from experienced professionals to navigate your path. 4. Leadership: Take initiative and inspire others, regardless of your title. 5. Empathy: Understand the needs and motivations of your team and stakeholders. In software, experience is valuable, but strategic decisions are even more powerful. Don't let the "experience myth" hold you back. Redefine your worth, take bold action, and go after what you deserve. --- PS: These numbers are for the USA, but the same areas apply to growth all across the world. Want to achieve the same? Start with my lesson, "Brain Powered Goal Setting." Learn how I co-create goals with my coachees that get them turbocharged for either a role at FAANG+ or a promotion. I'll also share sample goals of the software engineer and engineering manager so you can craft your own. https://lnkd.in/g7_N8sNh

52

10 Comments

"Comment your code" was advice I heard often early in my engineering career. It reminded me of teachers telling me to show my math work. I learned the former, but never got around to the latter. An engineer first realizes the importance of comments when they inherit a project without comments and have to make sense of it. The point is further reiterated when they have to review code that they wrote themselves years later and struggle to remember the purpose. I don't need to stress the value of comments in code, but what is a good comment? 💡 Option 1: Comment everything Some teams treat comments as a replacement for long-form documentation, listing what it does, how it works, how it connects to other parts of the application, and where it's used. Some include the ticket numbers that prompted the ticket. The comments are muliti-line, exhaustive, freeform insights into a block of code. 💡 Option 2: Less is more Some teams instead opt for terse documentation. The Linux Kernel documentation puts it perfectly: explain what or why, but not how. The thinking is that comments should not be a replacement for understandable code, but should provide the context that can only come from verbal explanation.    My preference is for terse comments, what do you prefer? #CodeQuality #SoftwareDevelopment #JavaScript #OpenSource #Linux

20

This morning I've got a guest post on Google's Open Source Programs Office blog: what to do when your open source contribution stalls out. There are posts and posts about how to improve contributor experiences from the maintainer side, but I couldn't find much about how to push through a rough contribution process from the contributor side. Turns out you, as a contributor, actually have quite a lot of power here! I wrote down some of the strategies that have worked for me and my team as we contribute to the Git project; they apply for open source work, but also for any kind of decision stalling out. https://lnkd.in/g3eD6W4N

26

2 Comments