Code Corp

🚀 Corporate return-to-office mandates have restored a critical recruiting advantage for startups. Before the pandemic, startups could attract top tech talent. They did not need to match Big Tech's high pay. How? By offering remote work—a benefit Big Tech was reluctant to match. This allowed startups to attract top talent without breaking their budgets. 👉 The pandemic leveled the playing field, but now that advantage is coming back. Corporate CEOs are doubling down on in-office work to improve collaboration. Startups can capitalize on this shift by building remote-first cultures where collaboration thrives. Mob programming is one example. A full team can be on a video call at the same time, solving the same problem. The result is zero communication lag and fully cross-functional problem solving. 💡 Practices like this can keep your culture strong. Employees feel more connected and less siloed. They feel empowered to act. Most importantly, customers get a better product. 📊 I'm not talking about hand-wavy stuff, either. Practices like pair programming have been academically studied. The Costs and Benefits of Pair Programming is a well regarded study by North Carolina State University. It showed us that this is practical stuff with real benefits. ✅ Even better, these strategies are measurable. Is remote work as a benefit an effective recruiting strategy? Candidate feedback and metrics, like offer acceptance rate and time-to-hire, provide clues. Does mob programming improve collaboration? Employee and customer feedback provide clues here. Now go differentiate your recruiting! 💥 If you need help, let's talk! 💬 P.S. If you need some inspiration, Spotify's "Our employees are not children" is great positioning 😀 #recruiting #startup #tech

Here's three interesting LLM prompting techniques I learned from reading Prompt Engineering for LLMs (O'Reilly early release). -> Did you know you can assess an LLM output without even looking at the output? 🤯 One of the coolest things in the book is how the author's used logprobs to judge a language model's confidence on code completions for GitHub Copilot. They used the exponential average of the logprobs of the first part of the LLM output to estimate how confident the model was in its output. This technique gives you a numerical assessment on the quality of the LLM output without even looking at the output. -> Did you know that positive directives like "Though shalt preserve life" can give better results than negative directives like "Though shalt not kill"? 🤯 Even better is adding some reasoning for your directive: Though shalt not kill since the act of killing disrespects the other person's right to life. And even better is avoiding absolutes: Though killest only rarely. -> Did you know that using three characters in your prompt can produce better results than two? 🤯 The idea is to create a chat-like structure using a chat-trained LLM. The "user" and the "assistant" have a conversation about a third person, the subject. The user asks the model to complete a task for the third person. The user describes what the third person likes/dislikes. Then the assistant uses these references for its completion. This could produce better results than the user being the subject. Rather than "Give me travel recommendations for Italy. I really like coffee" we can try "Provide travel recommendation for Jane's trip to Italy. Jane really like coffee". Take a look at these tips and more in the book review on the Code Corp blog: https://lnkd.in/ebHbHqyZ #llm #ai #openai #anthropic #genai

📉 Premature Optimization Can Sink Your Startup Software developers will get delivered a solution and are then asked to design the implementation. This results in too broad a problem space. It's much better to narrow the problem space. We should use tool A rather than tool B because it's faster. We should use framework X instead of framework Y because it scales better. Aside from solving the customer problem, the only other problem you have on day 0 of your idea is maintainable code. Scale, latency, and other problems have not yet been identified as problems for the business. Don't bother trying to solve them. Maintainable code is a problem from the start. We want to iterate quickly. We want software developers to be efficient. We can't solve the customer problem if these things aren't true. With this in mind, we can ask our software developers to design the implementation for a hypothesis that is also maintainable. This narrows the problem space considerably. It can help you avoid unique, Frankenstein-like architectures and designs. In the early days, maintainability as a requirement will often lead you to frameworks like Django (Python), Rails (Ruby), etc. The frameworks have been around for many years. They've been battle test in production by startups and enterprises. They're largely bug free for vanilla implementations. The have excellent docs that work for a wide audience. Deployments and observability are easy on a number of platforms. In other words, they allow you to focus on the customer problem and maintainable code. Read the full blog post on the Code Corp blog: https://lnkd.in/eU4nk98Y

💡 A Simple Hack for Software Engineers to Build Trust 💡 As software engineers, we tend to focus a lot on hard skills—like programming and system design—but often under-index on the soft skills that are just as crucial to success. Here’s a little hack to develop better soft skills: When talking about someone, imagine they’re part of the conversation. This simple trick helps ensure that you’re only saying things you’d be comfortable sharing directly with them. Why does this matter? Because in the workplace, what you say often gets back to the person. If it’s something you wouldn’t say to their face, it can erode trust. And when trust erodes, it becomes harder to collaborate effectively—a critical part of getting things done in any technical team. Trust is the foundation of collaboration, and to achieve things that are worth achieving, you need the help of everyone around you. So, next time you’re discussing a colleague, picture them in the room. Better yet, if it’s worth saying, consider telling them directly. This little tweak can help you build stronger relationships, which leads to smoother teamwork and lasting success.

🚀 Unlocking Speed: How Fast Iterations Drive Customer Value Delivering value to your customers quickly is critical, but let’s be honest—most of your first ideas won’t hit the mark. That’s where the iteration loop comes in. The loop is simple: identify the customer problem, develop a hypothesis, build a solution, and gather feedback. The faster you move through this loop, the sooner you’ll find out what works—and what doesn’t. Here’s how to speed up each phase of the iteration loop for maximum efficiency: 1. Customer Problem Identification Everything starts with identifying the #1 customer problem. If you’re solving the wrong issue, it doesn’t matter how fast you build—it won’t resonate with your users. Align your entire team, especially your engineers, on what problem you’re trying to solve. The better the team understands the problem, the better the solution will be. 2. Hypothesis Development Once the problem is clear, the next step is to develop a hypothesis. This should be a team effort. Involve your engineers in this process—they understand the code and can anticipate challenges. With their input, your hypothesis will be more grounded in reality, and you’ll avoid pitfalls down the road. 3. Build Quickly The goal here is to bring your hypothesis to life, but don’t aim for perfection. Use feature flags to push half-baked features out the door quickly. This lets you test solutions with real customers without fully committing to a final version. Automated testing is also crucial—manual testing slows down the process. By automating tests, you ensure that each iteration runs smoothly without piling on technical debt. This approach creates exponential efficiency, where more tests don’t mean more manual work. 4. Feedback Phase Feedback is where the magic happens, and it’s not just for product managers—it’s for the whole team. Including your engineers in this phase helps them see how their work impacts real customers. Whether you’re on a live call with the customer or sharing recorded feedback, make sure the whole team is aligned on what worked and what didn’t. This shared understanding improves future hypotheses and speeds up the entire loop. By improving the speed and collaboration within each phase of the iteration loop, your team will get better at identifying what doesn’t work, faster. And the sooner you discard bad ideas, the sooner you’ll find the right ones. This isn’t about rushing; it’s about testing, learning, and adapting quickly. At the end of the day, if your engineers can start with a hypothesis in the morning and put a testable feature in front of a customer by the evening, your iteration loop is working. Faster iterations lead to faster learning and, ultimately, delivering more value to your customers. Read the full blog post on the Code Corp blog: https://lnkd.in/e--iMZ6R

Actually, as a Software Engineer, I would embrace founder mode. Paul Graham’s essay on “Founder Mode” (https://lnkd.in/dax6vREz) got me thinking: why don't we, as software engineers, do more to learn directly from our founders to enhance our skills and better understand our customers? This isn’t about asking the founder what to do or inviting micromanagement. It’s about seizing the opportunity to learn from the unique ways founders think and approach problem-solving. Think about it—inviting founders into our sprint reviews and problem-solving sessions could provide a wealth of knowledge and new perspectives. They often have a deep connection to the customer and a clear understanding of the problem we’re trying to solve. By listening to their insights, we can gain a better grasp of the “why” behind our work, beyond just the technical details. Imagine learning how the founder identifies a real customer problem, develops a gut feeling about potential solutions, and decides when it’s okay to ship a quick, less polished version to gather feedback. These experiences can sharpen our critical thinking and help us align our efforts more closely with the company’s mission. It’s about understanding their decision-making process, not to emulate it exactly, but to adapt the parts that make sense for our own growth and the team’s success. By welcoming founders into these discussions, we’re not changing who we are as engineers. Instead, we’re broadening our perspectives and enhancing our problem-solving skills. Let’s take advantage of these learning opportunities to connect more deeply with our work and drive real impact. Read the full post on the Code Corp blog: https://lnkd.in/dApiiDti

Pieter Levels (Levels.fyi) recently caused a stir in the tech world with his “solopreneur” business. 🍿 Read the full blog post on the Code Corp blog: https://lnkd.in/eNvPge4Y After his interview on YouTube, reactions were split. Some people thought Pieter’s practices were completely right, while others felt he was doing everything wrong. This shows a common problem in our tech community: thinking in black-and-white terms. In his interview with Lex Fridman, Pieter talked about his unique way of developing software. He also shared his thoughts on venture capital-backed frameworks. One of the most discussed moments from the interview was when Pieter explained why he doesn’t use a staging environment: “No. I’m too lazy to set up a staging server, so nowadays I just deploy to production. Look, it’s idiotic at any big company. But for me, it works.” The responses to this interview were varied. For example, Theo Browne, a well-known influencer, said: “Going on the record to say @levelsio’s method of writing software is based af, and we can all learn from how he prioritizes delivery over everything else.” On the other side, @ImLunaHey had a different view: “No, he’s not an ‘absolute chad’; he’s a liability. I don’t know why anyone would see this as a good thing. It really shows he cares more about money than writing good code.” These different opinions show how limiting it can be to see things in black and white. As developers, we need to understand that every situation is unique. Pieter’s approach works for him because his setup and customers are different from yours. That’s why his solutions are different. We should let context guide our decisions in software development. If a developer deploys straight to production, consider their situation. A one-person team isn’t the same as a 40-person team or a company aiming to grow globally. When I worked as a Fractional CTO at an early-stage startup with ten developers, I was surprised to see complex solutions like RACI being discussed. RACI is meant for large corporate environments, not small startups. At another company with only two developers, they had four environments: local, dev, staging, and production. Every change had to go through each environment, causing delays. We decided to put unfinished work behind feature flags. Developers merged code daily, skipping the staging step, so changes went live almost every day. Pieter's has a solution to a problem he had. Do you also have that same problem? If not, this is a solution in search of a problem. Make sure to understand the problem that solutions were designed to solve. Perhaps you have a similar problem, but your context is different. Let's say you aren't a one-person dev team. Does it make sense to adopt a solution designed for a one-person dev team? Probably not.

Exciting News: Code Corp is Officially Launched! 🚀 For the last couple of years, I've built LLM-based apps. I've also worked with engineering teams behind the scenes. Today, I’m thrilled to share that my consulting company, Code Corp, is officially live! We’re passionate about creating software that makes a real difference—whether it’s helping companies solve tough problems or guiding teams to build software designed for growth. What we offer: • App Development: We'll bring your app to life so you don't have to deal with the hassle of hiring a full-time engineering team; • Fractional CTO: We can serve as a part-time leader for your engineering team so you don't have to make the big commitment on a CTO; • Advising & Coaching: We can help get the most out of your team with a bespoke advising engagement. Let’s create something amazing together! I’d love to connect with anyone interested in learning more. Check out our website at https://www.codecorp.us and let’s chat!