Valentyn P.

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

Public Service Announcements to recruiters. If you have the same job post you re-publish every day for many weeks, we notice. This gives hesitation to apply as we have no idea why you rejected the dozens of other candidates that commented "Interested" on your previous posts. Please provide more details about the position so that it's easier for candidates to know if they are a fit or not. If your intent is to build a pool of candidates, please be candid about it and openly say "Need iOS developer to build a pool of candidates". Believe me, they will still apply.

81

8 Comments

I keep hearing the idea that pull requests are bad and that developers shouldn't do them. Well, to me, most of these arguments are somewhat of a straw man variety and they encourage throwing the baby out with the bathwater. Pull requests aren't the problem. Pull requests won't prevent you from doing continuous delivery. The problem is pull requests that take a long time to review and approve. This is the thing that will prevent you from doing continuous delivery. But this is a very avoidable problem. It doesn't have to be this way. In our team, PRs don't normally take long to review and things in the trunk are being updated regularly. So it was in my previous team in my previous place of work. I worked in at least three different teams where we would try to get rid of PRs to see what will happen. In all of those cases, we had to get back to doing PRs because removing them caused more problems that we were trying to solve by removing them. I get it. It may work for some teams that do pair programming all the time, which I see as the only way to keep the code quality up without the PRs. However, this approach will not suit every company and every developer. Many developers I know will find it exhausting having to pair-program all the time. Even when you pair program, PRs still have their use. Just before you push all those commits you created, you can create a PR to view all the challenges to make sure you haven't missed anything. You will not only be able to verify that no temporary code changes go in, but you will also create a nice audit trail of who made the change and who reviewed it. I even sometimes create a PR for my own changes because because it's a tool that makes a pre-push verification very convenient. PRs are just a tool. Just like any other tool, it can either be used or misused. It only causes problems when it's misused and not when it's used properly. This tool may not be useful to you, in which case you may discard it. But you may also find out that it's not as useless as some people say it is and it won't stop you from doing continuous delivery, as these people say.

38

26 Comments

You want to hire the best developers, right? Collaboration in technical recruiting is a must. Here's why... A-Players attract other A-Players. - Use your team to make referrals - Offer bonuses for successful referrals - Engage with past candidates Having a team that is passionate is crucial. - Work together to find the best candidate - Everyone has a different skill set Collaboration can identify the intangibles. - How well will this person work in a team? - Will they adapt if the scope changes? - What is their communication style? There's strength in numbers. But, you need a great recruitment roadmap to get there. Make sure everyone on your team is working together effectively. And, always be ready to change up your approach.

14

The biggest names in tech are all over the xls which proves the US government is complicit in destroying the employment market for US workers. https://lnkd.in/erAdpXrE

4

4 Comments

🚀 Law as Code: Progress Update 🚀 Yes, the law can be expressed as code. And yes, LLMs can scale the translation en masse. I've reached the proof-of-concept stage with Json-Lawgic, and while the results are promising, key questions remain: 1️⃣ How accurate is the expression of laws? 👉 Subjective and evolving, but I've built an evaluation tool to begin testing this! 2️⃣ What are the practical applications? 👉 #RulesAsCode systems aren't new - this approach can be a means to build them more quickly. Furthermore, legal chatbots could call validated code as a tool to enhance their accuracy. 3️⃣ What's next? 👉 Feedback and collaboration so I'm not building in a vacuum! Huge thank you to Jason Morris and Damien Riehl for their advice and direction - this project is progressing a lot further than I expected thanks to your insights! How do I plan to enhance this project further? 🔧 Prototype a chatbot using encoded laws as tools   🔗 Build rule linking across statutes   📈 Scale with open-source LLMs (so OpenAI doesn't break my bank 💰!) To read more about my evaluation tool and the feedback I've received from experts on this subject, I've made a full blog post here: https://lnkd.in/ghD7p5je This project is open source, so feel free to check it out and give it a ⭐ to keep track as it grows: https://lnkd.in/gGV_b8pV To play around with what I have so far, here's the showcase: https://lnkd.in/gtTitarQ And if you have thoughts, feedback, or scathing criticisms - let's chat! #AI #ComputationalLaw #AccessToJustice #JsonLawgic #RulesAsCode

17

1 Comment

I often see something like the following line in job postings: 'Required: Bachelors degree in Computer Science or comparable experience considered'. What is comparable experience here? One year as a Backend Software Engineer? Three years experience: one year as a backend, one year as a front-end, and one in a dev-ops role? Two years as 007's assistant? If it is years of experience, I can promise you, working in industry as a Software Engineer is generally, nothing like learning it at University. This leads me to think that what they are really looking for is proof that you are capable of doing the job, so either a degree or industry experience that they deem acceptable will do here for them. You (with rare exception) do NOT need a Computer Science degree to be a capable Software Engineer. Stop making it a requirement.

121

42 Comments

"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

It’s official: landing a software engineering job is tougher now than it was just a few years ago. With many startups shutting down and big companies laying off employees, candidates with 0-5 years of experience are feeling the pinch. What can you do? Shift your storytelling from tools and languages to the impact you've made. Highlight who your users were, how you improved their lives, and any recognition you received. Remember, outcomes matter more than just the technologies you used!

2

If you want LinkedIn impressions without putting in any hard work, I’ve got some tips for you: - Say TDD sucks. - Make fun of a silly sales pitch. - Share a meme. - Tell a joke. - Post a picture of your test suite (green ticks) or say you never have time to write tests. - Say PHP doesn’t suck. - Say Clean Code exists. Welcome to the jungle. Watch it bring you to your n-n-n-n-n-n-n-n knees, knees.

54

21 Comments

Developers, never forget that interviews should go both ways. Yes, the interviewer is there to learn about you, but you’re also there to learn about them. If you’re interviewing at an early-stage startup (e.g. less than 10 employees), here are three things you might want to find out during the first stage: 🗣️ Where are they currently at with app development, and how do they envision plans to change as the business grows? 🗣️ When resources and budgets are limited, where does app development fit into their priorities, and how would your role be impacted? 🗣️ What challenges have they faced (or anticipate to face) in development so far, and how do they expect to overcome them? Sometimes, interviews can seem one-sided, but don’t be afraid to speak up and ask questions. It’ll show the interviewer that you’re engaged, interested, confident, and can use your initiative. (Plus, if they don’t encourage you to ask questions, it’s probably a red flag!) #DeveloperOpportunities #DeveloperJobs #MobileDeveloper #InterviewTips

8

1 Comment

🏎️💨 Making of a Ridiculously Fast™ API client in R. Why my package is **~17x faster** than the community alternatives that call the **exact same API endpoints**. 👇🏽**design choices matter** ✨ https://lnkd.in/ggi_2XyQ

129

2 Comments

Jr. Devs, Today marks 2 years at my current employer. Yay! Some of you will celebrate with me because you are struggling to get your first job or maybe even your first interview. Some of you might think celebrating only 2 years at a job is weird. For me, in my career experience, 2 years is a milestone… unfortunately. In fact, on average, my employment at a company has lasted about 2 years, often less. There are varying reasons why, from being a contractor and finishing projects to being part of several layoffs to moving on to other opportunities. Now, that doesn’t mean you will have the same path. I have a friend who’s been at the same company for around 20 years as a developer. So, I’m not saying your journey will look like mine. What I’m saying is to prepare yourself for the reality that once you get in, it may not be everything you hoped it would be. It may have twists and turns that you don’t expect. You may feel like everything is great one day only to have the rug pulled out from under you the next. It’s all part of the journey and you can flourish in it. But you need to recognize the possibility and be prepared to handle it well when/if it happens.  So, when things are going well… celebrate, like I am today! If you want to know more about my journey, you can watch this very, very long YouTube video: https://lnkd.in/gqRJ_uGU Maybe it will be an encouragement on your journey as well! #juniordeveloper #mentoring

19

1 Comment

Developers – good luck getting promoted if you: - build features that don’t relate to any OKRs, - write documentation for internal tools that no one uses, - spend resources optimizing a system without any traffic, or - refactor working code because it’s not written in your preferred style. Prioritization of effort is the highest leverage skill you can learn as a SWE. Your company doesn’t care if that shiny new tech stack is trendy. Only whether it will help you solve real problems for your customers. What good is fashioning a bigger mainsail if you’re headed off course because of a broken wheel?

218

59 Comments

How I helped a client hire a senior .NET engineer for $40k below market rate: Recruiting top tech talent on a budget isn't easy. But it's not impossible. Here's how I helped a client land a senior .NET engineer despite offering $40k below market rate: 1. Gather market feedback — I sourced candidates for a day, collecting consistent feedback that the budget was too low. This data helped build a case for a higher budget. 2. Negotiate budget increase — Using the market feedback, I convinced the client to increase the budget by a few thousand dollars. 3. Adjust skill requirements — We identified which skills were absolutely necessary and which could be learned on the job. This opened up the talent pool to mid-level developers ready to grow. 4. Highlight non-monetary benefits — We emphasized their fully remote work environment, company culture, and unique perks to attract candidates. 5. Target the right candidates — By focusing on mid-level talent eager to grow, we found someone who met technical requirements, fit the budget, and made an immediate impact. The key? Finding middle ground. Not every company can compete with big tech salaries. But by adjusting expectations and highlighting unique benefits, smaller companies can still attract top talent.

11

🤔 "Hey, I found you a Senior Developer for $10/month!" ...said no legitimate recruiter ever. Let's talk REAL numbers, folks: Senior Developer in Ukraine: $5-6K USD ($8-10K AUD) per month. And yes, these are current rates DESPITE the ongoing war and global crisis. Let that sink in. Here's a reality check: Once peace returns to Ukraine, Western investment will flood in for rebuilding and expansion. Tech talent prices? They'll skyrocket even further. Ukraine's IT sector isn't just surviving - it's positioning for a massive post-war boom. 🚀 And that "AI will make everything cheaper" fairytale? Sorry to burst your bubble, but it's doing the exact opposite! 🔄 The AI revolution isn't shrinking dev costs - it's forcing businesses to either digitize or die. More digitization = More demand for developers = Higher prices. Basic economics, people! When someone promises you a "senior developer" for the price of a Netflix subscription, ask yourself: - Are they also selling beachfront property in the Sahara? 🏖️ - Did they inherit this developer from a Nigerian prince? 👑 - Do unicorns handle their project management? 🦄 Yes, I get it. The global tech salary disparity isn't fair. Sometimes you might strike gold and find an amazing talent for a fraction of the market rate. But here's the hard truth: Building a business on luck is like building a house on TikTok trends - entertaining but not sustainable. 💭 Curious: What's the average developer salary in your company? Drop it in the comments (and no, "exposure dollars" don't count 😉) #TechRecruitment #DeveloperSalary #TechIndustry #AIRevolution #RealTalk #TechHiring #SoftwareDevelopment #UkraineTech

5

A few controversial things I believe about writing code: 1) Code should be comforting, not just functional. I’m not saying it should be flowery or overcomplicated. I’m just saying it should be easy to read and pleasant to navigate. 2) Comments should be personal. Contrary to popular belief, dry comments are a waste of time. “Initializes variable.” “Checks condition.” “Executes loop.” Generic comments are hard to remember and easily overlooked. 3) Humor belongs in your code. “Most people” keep their code dry and formal. Which leads to… Boring code. Disengaged devs. Missed opportunities for connection. Clearly, what “most people” do doesn’t work. So, add a little personality. 4) Consistent formatting isn’t negotiable. 99% of the time, neglecting formatting is a giant mistake. Instead, Robert Martin’s “Clean Code” framework offers a path to elegance without clutter. Consistent naming conventions. Proper indentation. Thoughtful use of whitespace. 5) Pursuing code efficiency at all costs is a silly goal. Because readability and maintainability often matter more. Code that’s easy to understand is a better pursuit in life. It saves time. It reduces errors. It fosters collaboration. If we all have to spend time there anyway, why not make it nice? In a world of deadlines and conflicting requirements, your code can be a refuge, a place of quiet contemplation. 🪷 Read this post and more on my Typeshare Social Blog: https://lnkd.in/gjZbQJrP

8