Posts Tagged ‘software engineering’

From a recent LinkedIn contribution:

Be mission-focused and be prepared.

Pick – or at least know – your team ahead of time.

Delegate to those best suited.

If you’re also a contributor, delegate your weaknesses.

Make it about the Vision, the Mission, and the Team. Connect with your people. You can’t succeed if it’s not all three.

If the team believes in the vision and the mission, they’ll work to believe in you. If they already believe in you, they’ll trust your vision and work to make the mission succeed. Trust them to follow through. If you run into trouble, ask THEM why, not just yourself. Correct as necessary.

When you have to be a leader, it’s about Vision, Mission, and Team. It may be hard getting the hang of it. As you see success, it’ll come easier.

My thoughts, originally posted on LinkedIn:

Documentation must be part of your process. If you’re documenting everything when you’re leaving, you’ve failed everyone. Just like workouts, make documentation routine, and you’ll do it every time. It’s OK to reject pull requests that are missing documentation. Perhaps make proof of documentation part of closing any Feature or Epic. If people complain, ask them how they react when entering a project with no, little, or poor documentation. They tend to change their tune when looking in the mirror.

A recent contribution I made on LinkedIn:

The act of looking for an internship is a great first step – good for you! There are many resources. First, check with your professors – they may know of open internships. Next, your school’s Careers or Counseling office. They know the sites most often leading to successful internship connections. Third, check known internship sites, like Handshake at https://joinhandshake.com/. Fourth, check out Meetups / Meetup.com. It’s often who you know, not just the little what at this stage in your career. Meetups help you create relationships in your industry of choice. Best of all, they’re free, and there’s often pizza, so you can have informal, less stressful, conversations. Good luck!

Good. You admit it. Now go do something about it. You may or may not know your weaknesses. If you do, go brush up on those. Challenge yourself with tasks of increasing complexity. If you don’t yet know, ask a trusted mentor/friend/coworker/manager where you feel you need improvement, or at least a starting point on where to begin. There’s nothing wrong with asking for help – that’s how you grow. You did it as a kid, and you have to do it as an adult. A growth-driven mindset vs. an ego-driven mindset will take you far. You’ve got this!

This is a copy of my answer on LinkedIn Experts from April 19, 2024.

I originally posted this as a LinkedIn contribution. Making sure you can read it on my blog πŸ˜€

If it’s your first programming language, the language itself doesn’t matter. It’s the thought process that counts. The training to:

  • think logically,
  • break a problem or process into its component parts, and
  • understanding how those parts intermingle.

If you’re just looking to learn another programming language, you don’t need to spend money. There are FANTASTIC free tutorials out there. Check out Microsoft Learn https://learn.microsoft.com/en-us/training/ as a good starting point. You can follow entire tracks, or just one-off topics. There are videos, code examples, coding environments, tips and tricks, and more. To be fair, MS Learn is not the only option, but I only have 750 characters and you have a search engine.

I recently enjoyed a “fireside chat” at the Indy .NET Consortium, a meetup I run for local .NET developers.

I’ve had some good conversations with interns and others recently who have struggled with or had insights into this transition. My experience as a young developer was a bit different, because I didn’t take the traditional path of high school -> college -> workforce. Mine was high school -> college -> co-op -> left-school to work and create career -> go back to school -> leave school to work again -> work for startup -> work for consulting firm -> start a business -> shut down business and go back to workforce.

Our October 5 meetup talked about how the traditional path can be a bit jarring. The way I explained it to my employees was “In school, you can get an A, B, C, D, or F. And that’s OK. You learn from it. But in the workforce, you either get an A or an F. You can have as many Fs as you want, as long as you end up with an A. Sometimes, within reason, I’ll accept an A- or B+, but it’s rare. We’re paid to deliver, not pass lessons.”

You can watch the entire discussion below: