Regina Locicero

"I don't like leetcode style interviews!" See I wasn't making it up! Kurtis Nusbaum tells us more about why engineers don't like leetcode and the types of interviews that lead to a more enjoyable and effective interviewing experience.

4

1 Comment

Confession time: I used to think TypeScript was overkill. Boy, was I wrong. It's become my go-to for building robust GEN AI applications. Key benefits I've experienced: 1. Fewer runtime errors 2. Easier code maintenance 3. Improved team collaboration Pro tip: Use interfaces to define API responses. It's a lifesaver. How has TypeScript improved your development process? #TypeScript #SoftwareEngineering #socialsonic

45

1 Comment

Feeling compelled to rant a bit. (All opinions my own.) Social media rarely communicates useful knowledge or reality. It is easy to wax poetic about programming. It is many orders of magnitude more difficult to actually do the work of studying and implementing a production-ready feature. Writing a post saying “Developers must be cautious to handle edge cases or their users will lose data! Follow for more software tips” takes seconds and floods platforms. ACTUALLY writing and testing implementations that do that take months or years, and will NEVER be posted on social media, because it is the product of salaried engineers that cost money to employ, and is thus intellectual property that cannot be shared under threat of lawsuit or possible criminal prosecution. That is reality. Full stop. Social media lies. Are LLMs a useful tool? Probably. You can find names of algorithms given a problem description in plain English, or get sample code to jump into a library quicker. That is crazy useful. They are good tools to ask questions and get a result (that you MUST follow up and VALIDATE FOR YOURSELF.) But they are NOT replacements for engineers. I'm tired of reading people lying that they are. Show me an LLM that won't hallucinate Swift Testing into Jest and JavaScript, like Claude did for me last week. Absurd. Show me an LLM capable of writing FreeBSD kernel code that understands the kernel’s lock state and properly manages locks without error, like my roommate did in college. How can you validate that output? This notion that LLMs will replace human beings is a marketing lie. It infantilizes the effort of careers like software engineering, treating years of hard graft, as well as academic + practical knowledge, and even our human capability to adapt, grow, and be creative upon tens and hundreds of thousands of years of our species' history - as though text search is worth more than all that. Those promoting ML replacing human beings, in any field, are clueless influencers and/or have financial interests. It misleads the general public about these technologies and their limitations, which is extremely dangerous. We need, frankly right now especially in the USA, to seriously course correct away from widespread lies and anti-intellectualism, to be more willing as a people to study, tackle, discuss reality, and to have more agency. Complex topics are not "smart people" things. When I hear people say this it deeply depresses me. It's telling yourself you can't/shouldn't learn, when that is the beautiful capability of us humans. We are in a golden age of many freely or cheaply accessible courses, textbooks, and papers. I wish we had systems that better promoted truths and encouraged diversifying oneself into knowledge outside one's specialization. There are too many lies, simplifications, and hallucinations being broadcast. It's a shame, and threatens our futures. #socialmedia #programming #softwareengineering #knowledge #technology

17

Need to request files from clients? It’s super easy with the new File Requests feature! Go check it out.

16

If you're not a software engineer, keep scrolling. I've been an engineer my entire career and have led engineers for 9+ years. I love this profession. But there's one mistake I see mid-level engineers make too often: Not being clear about the value they're providing. There are 4 areas in which engineers provide value: Technology, Product, Process, and People. But no one gets to Product, Process, or People without mastering Technology. And I'm here to tell you there is a lot of value in the technical understanding. Don't try to scale the ranks before you build depth there. We’re engineers. No matter your title, you need to be comfortable building software. Ideally, you should love it. When you’re progressing through your career, it’s exciting to get tapped on the shoulder to lead a product, overhaul a DevOps process, or manage people. And when you get these opportunities, take them. But make sure you stay close to the engineering part of the process. Because as soon as your coding capabilities start to dwindle, you lose value. That sword needs to stay sharp. A principal engineer who is either a) not interested in being hands-on or b) no longer capable of being hands-on, can’t succeed in leading a team. Today I’m a CTO. But if my team needs me to write code, I’m there in a heartbeat. So my advice to younger engineers is: Stay close to the tech. It makes you better at Product, Process, and People. If you’re an engineer reading this, know that I appreciate you. This isn’t an easy job, and I respect you for doing it. P.S. In the spirit of this post, here's a photo of me with much longer hair from *slightly* earlier in my career.

51

7 Comments

I've recently wrapped up a major project, but I already find myself yearning for an interesting problem to dig into. As I've matured into my engineering career, I've noticed that it takes more depth and complexity to really engage me than most of my historical hobbies can provide. There are some stand-out exceptions to that trend though, and that leads me to my point for this post; Factorio[1]. Nothing else has accurately simulated the highs and lows of coding and software design, while also still being an enjoyable escape for my down time. It accurately simulates an accelerated production development experience in so many ways, all by enabling classic short-term tradeoffs that become long-term pains. Just want to hit that next tech milestone today? Sure, slap some spaghetti conveyor belts down and you can have it - but now the next milestone is at least twice as hard! 😅 I wish I could force every PM and C-Suite in the industry to play it up to the rocket launch tech...but maybe this post will at least convince some of you to give it a try! [1]: https://lnkd.in/gTCwC2gc

6

2 Comments

From "tunnel rat" to senior engineer with FAANG on the resume - a TL;DR of my salary journey in tech: 2005-2015: Worked for the MTA in NYC as a Track Worker. I was literally swinging hammers on the rails, laying down tracks. 2015: Attended General Assembly, a 3-month bootcamp, and learned how to code. Quickly resonated with Front End development. Was the 1st in my class to get a job offer and by the summer I was working at Accenture. This represented an $11k raise from the MTA. 2016: Gave myself a $22k raise and accepted a job at L2 Inc. My first startup! I learned React here as well. Good times. 2017: Gave myself a $24k raise and accepted a job at Transfix. To this day, this was one my my favorite companies to work for. This was a hard company to leave, but I was early in my career making up for lost time in the tunnels. I also spit a verse over a dope beat as my farewell email and sent it to the whole company. 2018: Gave myself a $48k raise - welcome to Bloomberg! At this point I thought I plateaued. I was now making more than 2.5x what I was at Transit. Talk about a life change! God is good. I had no plans of leaving until drastic internal changes happened. 2019-2021: Took a 3k base pay cut but... joined Meta and give myself a significant overall raise due to those sweet, sweet RSUs. God, is this real?! Some of the best working experiences I've ever had. What a ride. 2021-2023: Base pay bump of 30k - now I'm at Coinbase. And still, those sweet, sweet RSUs. Liquid cash is always the best! This would be the company that made me realize I had the "golden handcuffs" on. It's SO hard to walk away from RSUs, but my family would ultimately help me realize there's more to life than money. 2023 - present: 30k base pay bump as I joined the good ship Docker, Inc. Pretty much at the top level (financially) of being a senior engineer but the golden handcuffs are finally off. Join me and 🌻 Anna Miller this Thursday as we continue our conversations about my career journey. The whole point is to give people insight and encouragement on theirs. 🫡

102

23 Comments

I’ve been mentoring aspiring front-end developers on adplist.org for a year. One of the most common questions I get is “Should I learn [something]?” This “something” can be TypeScript, SQL, React, or any skill listed in job descriptions. Feeling the need to learn all these skills quickly can lead to anxiety. So, if you’re feeling lost and overwhelmed by the skills you think you need, try this: ✨ Know your ideal developer type ✨ Front-end developers can be very different. For example:  - You can be a CSS wizard that creates stunning animations. - You can be an accessibility expert that makes the web a better place. - You can be a library developer that builds tools like React used by thousands of developers. Each type requires different skills. As a CSS wizard, understanding how React works under the hood isn’t crucial. Focusing on one area, and you have less to learn and focus on what excites you. Discover your strengths and passions. By knowing your ideal developer type, you’ll find a clearer path forward. Read this post and more on my Typeshare Social Blog: https://lnkd.in/gwKjN3Mx

51

10 Comments

🚀 Exciting News! 🚀 I just registered for KubeCon in Salt Lake City! 🎉 I’m really looking forward to connecting with industry professionals, especially in the observability space, to exchange ideas, learn about the latest trends, and explore new opportunities. If you're attending, feel free to reach out—let's network! 🤝 Check out the event details here: #KubeCon #Observability #CloudNative #DevOps #Networking

21

1 Comment

I’ve read many books about design, but few teach bridging design, engineering, and business powers. Designing for Essential Values by Kazuo Tanaka is different because it: 1. (Re)defines the *purpose of design* in the modern age 2. Demonstrates how *design thinking* can solve problems This is the best design book I’ve read in response to emerging technologies and challenges like AI. It’s perfect for designers, engineers, and business owners alike. Although this book is currently only available in Japanese and Mandarin. I’ll summarize three key insights for you here: 1. Design is a confusing term 📕 From the book: We usually think of design as an action to craft form, but it involves skills like observability, discoverability, ideation, and visualization. 👍 Takeaway: Specifying the aspects of design is crucial to avoid confusion during conversations. 💡 Thinking point: Is this why we struggle to explain the difference between UX, UI, interaction, and product design roles? 2. Design is a procedure to organize, solve problems, and innovate 📕 From the book: Design is never a single point of action, nor is it specific to objects or events. 👍 Takeaway: Always think of design as an end-to-end process. A design phase with start and end dates doesn’t make sense. 💡 Thinking point: How can this concept be integrated into a team’s workflow? 3. Synergy between the sensational and rational minds is necessary to solve problems 📕 From the book: Whether by one genius (e.g, Steve Jobs) or through collaborations within an organization, combining different types of thinking is the best strategy for innovation. 👍 Takeaway: Be open-minded and consider opposite perspectives. 💡 Thinking point: Even if we aren’t geniuses, can thinking and learning outside of our comfort zones achieve similar synergy outcomes? What do you think about these ideas? Are these ideas practical? How might you apply them in your own work? Let me know your thoughts. Designing for Essential Values: https://lnkd.in/gWkm4XNM Read this post and more on my Typeshare Social Blog: https://lnkd.in/gVRZWR7w

2

I often get asked about what working at NASA is like. So, here are the top 3 skills I have learned as a Software Engineer at NASA, that every employer is looking for -- 1. Problem Solving and Critical Thinking: Tackling complex problems is a daily task. I've learned to approach challenges methodically, considering multiple solutions and often thinking outside the box to find the best path forward. 2. Collaboration and Teamwork: Working at NASA means being part of a diverse team of experts. Effective communication and collaboration are essential to ensure that projects run smoothly and achieve their goals. 3. Functional/Technical Proficiency: My technical skills have expanded significantly, particularly in areas like system design, code architecture, and dealing with high-volume data. Being exposed to cutting-edge technology and methodologies has been invaluable. These skills have not only enhanced my professional capabilities but have also enriched my personal growth. I'm excited to continue learning and contributing to NASA's mission of exploring the universe. What skills have you found most valuable in your career? #NASACareer #SoftwareEngineering #SkillsDevelopment

11

Some random coding rant ahead. Don't get me wrong, #Go is one of my favorite languages: many great features, awesome tooling and standard library etc. I'd likely pick Go in any situation when I need to get things done in time. While it's not the most fancy language, it was never intended to be one, and I appreciate their stance in this regard. That all said, I sometimes see annoying contrasts between design choices. Like, on the one hand, you're not allowed to have the ternary operator or less verbose error handling. Our way is to `if err != nil {}` until it hurts, and then a few more. Ok, well, anyway, that's all in a day's work for Copilot. But hey, in case if you missed it, now you can write `for range 10 {}`, because C-style syntax is too lengthy and old-fashioned! 🤷‍♂️

9

"Why aren't the designers and engineers sitting together?" I've asked this more times than I can count. At many large companies, designers and engineers are not only different job descriptions, they're often physically separated from one another. In 2012 when everyone learned that Apple would launch its own maps product on iOS, I was lucky to find the team within Google that would be responsible for launching the first version of a dedicated Google Maps for iOS app. When I joined the team, the engineers had a pod in one part of the building and the designers had a separate pod, ~200 yards away and out of sight. This created a dynamic where engineers would be handed design specs and tasked with implementing them, factory line work style. If you work on a design systems or product team, this might sound familiar. We were under immense pressure to launch. With Apple's new Maps app having been released in September, every day that passed was another day that Google Maps didn't exist on iOS. First impressions matter, and this created a tangible sense of accountability within the team. And yet, I couldn't shake this feeling that the separation of design and engineering was creating a quality bottleneck. Every day, I'd run over to the design pod with the latest prototype, ask tons of questions, and then run back to my desk to tune the design. It was super inefficient, and I was one of the only engineers doing this near-daily ritual. So a few months out from launch, I took over a conference room, ordered pizza, brought in a sound system, and convinced one of the designers (Viktor Persson) to sit with me in the room as we fine-tuned every single interaction in the app. Every day we'd bounce ideas, play with concepts, and fine tune micro interactions. From the bottom sheet gesture physics, to the app navigation, from localization ("hipster ipsum" mode was critical here), to the way the "swap directions" button animates when you tap it, we meticulously walked through every pixel of the application to make sure it reflected a degree of craftsmanship that we felt was critical for this v1. And the results showed. The v1 launch was one of the most stable, well-received product launches of that iOS era. I've seen this story play out many times over the past decade, both of my own volition and through enabling it with members of my team, and the same central ingredients have held true every single time: when you afford space for an engineer/designer pair to have full agency to own product quality together, this combo can move mountains. Ladders and job roles incentivize specialization, so it's up to leaders to create environments that encourage high-efficiency cross-pollination of talent, and to avoid the tendency for product design groups to default to the assembly line (i.e. "hand-off") model of work. Get your key designers and engineers together. Not just for a sprint, but for the greater goal of building something incredible together 🚀

44

2 Comments

Under the idea that the only dumb question is an unasked question, here's one for the void: When researching a company prior to an application/interview, how exactly does one determine what the company's "needs" are? This is an area that I struggle in. It's not because I'm not innovative or feel I don't have anything to contribute. Even after nearly 20 years, I still struggle with getting away from the military heirarchal mentality. I'm great at giving input on various scenarios I'm actively involved in, but as a junior (or outside) party, giving unsolicited advice to someone higher on the chain seems daunting. To that end, it almost seems arrogant to think I can propose an idea that a C-Suite executive or senior director hasn't already worked through. My abilities know no bounds, but I also try to approach people with a high level of humility. Or am I thinking too deep? A company NEEDS a software dev (which is why they're interviewing me), so I just need to illustrate why I'm the best fit for the job without proposing how to revolutionize the company? Thanks in advance for any input?

3

3 Comments

🎉 Big News! We've just launched the third book in our System Design Playbook series! I don't want to brag too much because, well, I'm just the guy who created this, but together with my tireless team (shoutout to Rohit Jain and Shubham Chandak!), we've worked hard to make system design concepts simple and digestible. Preparing for FAANG interviews, I remember the struggle of finding comprehensive resources—concepts were all over the place, and explanations often left more questions than answers. We aimed to fix that. Here’s what we packed into this book: 1. 𝗩𝗶𝘀𝘂𝗮𝗹 𝗔𝗶𝗱𝘀: Lots of diagrams because, truly, "𝘈 𝘱𝘪𝘤𝘵𝘶𝘳𝘦 𝘴𝘱𝘦𝘢𝘬𝘴 𝘢 𝘵𝘩𝘰𝘶𝘴𝘢𝘯𝘥 𝘸𝘰𝘳𝘥𝘴." 2. 𝗡𝗲𝗮𝘁 𝗘𝘅𝗽𝗹𝗮𝗻𝗮𝘁𝗶𝗼𝗻𝘀: No buzzwords, no fluff. Just clean, straightforward explanations that make sense. It's tough to write simply, but that's where the real effort lies—𝘪𝘧 𝘺𝘰𝘶 𝘤𝘢𝘯’𝘵 𝘦𝘹𝘱𝘭𝘢𝘪𝘯 𝘪𝘵 𝘴𝘪𝘮𝘱𝘭𝘺, 𝘺𝘰𝘶 𝘱𝘳𝘰𝘣𝘢𝘣𝘭𝘺 𝘥𝘰𝘯’𝘵 𝘶𝘯𝘥𝘦𝘳𝘴𝘵𝘢𝘯𝘥 𝘪𝘵 𝘸𝘦𝘭𝘭 𝘦𝘯𝘰𝘶𝘨𝘩 𝘺𝘰𝘶𝘳𝘴𝘦𝘭𝘧 - 𝘈𝘭𝘣𝘦𝘳𝘵 𝘌𝘪𝘯𝘴𝘵𝘦𝘪𝘯. We've included a sample from our latest chapter on Designing YouTube to give you a taste of how we approach teaching complex topics in a way that sticks. Download Full eBook: 𝗪𝗲𝗯𝘀𝗶𝘁𝗲: https://lnkd.in/dzUXgTwb 𝗞𝗶𝗻𝗱𝗹𝗲 𝗩𝗲𝗿𝘀𝗶𝗼𝗻: https://lnkd.in/dXPvFzju Happy learning!

46

6 Comments

The open source team I'm a volunteer for at Couchers.org is looking for (volunteer) UI/UX Designers. Come join us, we're fun! Our Figma designs can't keep up with our engineers...halp? Maybe you're taking a sabbatical and want something on your resume for that time. Maybe you wanna see what it's like to work on a project that has nothing to do with stakeholders or investors, where we just do stuff our users want and we think is cool. Maybe you're passionate about traveling and old school couchsurfing vibes and wanna nerd out about it on a team with other travelers. Or maybe you just love designing stuff and are looking for some public portfolio pieces? Join our volunteer team! More info here: https://lnkd.in/g_PwevB9 On a side note, if you're a software engineer with some experience in Javascript or Python and looking for a fun project, we're always looking for more people too. (Please I need more people to review my PRs lol). #uxdesign #uxui #figma #design #opensource #volunteer

13

2 Comments

This may be the best advice for engineers looking to advance in their career. Product impact will take you much farther than technical mastery. Having a product mindset can easily make you stand out and shine ✨ —and of course it’s great for your business. Technical skills clearly matter for engineers, but being savvy about how to create product impact puts you on a totally different level.

26

1 Comment

On this random Wednesday, if you’re a software developer thinking, for no specific reason, about pivoting into the impact space and want to talk about what FreeWorld is doing and why we’re growing so fast and how you can help, please reach out.

69

4 Comments