Avsnitt
-
One of the biggest challenges for all software developers in 2023 (and leading into 2024) - is simplifying their tech stack so work can get done. The continued explosion of boutique frameworks and libraries is making it harder than ever to manage complexity as the stack of tools and technologies we use on our projects grows.
Whether you're a software architect, senior engineer or developer, or any other role that encounters tools and technologies on a software project - the decisions we make about what frameworks, APIs, libraries, and other pieces of technology to use on a software project impact us all.
In this episode, I'd like to help you simplify your tech stack by sharing some of the things I've learned as a software architect about making informed and reasoned decisions about tech stack choices. I hope it helps you avoid some of the typical pitfalls we programmers can fall into when we select tools and technologies as soon as we find them - instead of stepping back and finding out if they're really high value enough to the team to adopt using them.
Get free access to TechRolepedia here:
https://jaymeedwards.com/access-techrolepedia/Download my free Career Guide here:
https://jaymeedwards.com/developer-career-guide/Need help with your career? Learn about career coaching: https://jaymeedwards.com/services/software-development-coaching/
You can also watch this episode on YouTube.
Chapter markers / timelinks:
(0:00) Introduction
(1:07) 1 THE DANGERS OF TECH STACK COMPLEXITY
(1:12) 1.1 Tool Overload
(1:40) 1.2 Decision Fatigue
(2:03) 1.3 Integration Challenges
(2:34) 1.4 Cost Implications
(3:26) 1.5 Diluted Focus
(3:44) 2 SIMPLIFYING YOUR TECH STACK
(3:52) 2.1 Prioritize Value
(6:35) 2.2 Embrace Versatile Tools
(7:39) 2.3 Standardize and Document
(8:50) 2.4 Seek Community Input
(10:01) 2.5 Regular Review and Upgrading
(11:33) Episode Groove
Visit me at JaymeEdwards.com
Find me on X as @jaymeedwards
Find me on Instagram as jayme.c.edwards
-
Instatechcoach is a livestream I'm doing on Instagram where I offer short, free career coaching for software professionals every Saturday at 1PM Central Standard Time.
You'll hear me discussing the career challenges of other developers, and answering questions about my own career, as well as The Healthy Software Developer show.
Follow me on instagram as jayme.c.edwards
-
Saknas det avsnitt?
-
Burnout is one of the most common dangers to programmers over their career, and I was no exception. Software development and programming can make it difficult to find a healthy balance between work and life. My burnout was a combination of self-inflicted bad decisions, things done to me, and circumstances in my personal life.
In this episode, I share the story of my own burnout and how I lost nearly everything. Through it all, I found what really matters in life - and work became a smaller part of it.
I hope this episode encourages you to share your own struggles to get help. Maybe some of the things I learned after going through burnout can also encourage you to keep going.
My wife Angie's podcast, "A past, repainted" is here:
https://apastrepainted.com/content/podcast/Get free access to TechRolepedia here:
https://jaymeedwards.com/access-techrolepedia/Download my free Career Guide here:
https://jaymeedwards.com/developer-career-guide/Need help with your career? Learn about career coaching: https://jaymeedwards.com/services/software-development-coaching/
You can also watch this episode on YouTube.
Chapter markers / timelinks:
(0:00) Introduction
(0:59) 1 SELF-INFLICTED BURNOUT CAUSES
(1:05) 1.1 People Pleasing
(1:41) 1.2 Overextending at Work
(2:03) 1.3 Side Gigs
(2:15) 1.4 High Expenses
(2:51) 1.5 Drug Addiction
(3:18) 1.6 Guilt and Shame(3:59) 2 OTHER-INFLICTED BURNOUT CAUSES
(4:16) 2.1 Political Lies and Manipulation at Work
(5:31) 2.2 Recurring Project Firefighting
(6:42) 2.3 Betrayed by a Coworker(8:04) 3 CIRCUMSTANTIAL BURNOUT CAUSES
(8:34) 3.1 My Child Struggled With Dangerous Addiction
(10:07) 3.2 My Father Died At a Young Age
(10:45) 3.3 9/11 Work Culture Changes
(12:04) 3.4 My Wife's Abuse(13:36) 4 BURNOUT TRIGGERS
(13:42) 4.1 Startup Partner Exited
(14:27) 4.2 Marriage Became Distant
(15:13) 4.3 Recurring Relapse of My Child
(15:54) 4.4 Company Bought Out(17:04) 5 MY BURNOUT SYMPTOMS
(17:12) 5.1 Chronic Insomnia
(19:03) 5.2 Uncontrollable Anger
(19:47) 5.3 Forced to Resign
(20:25) 5.4 Spent Emergency Savings
(21:29) 5.5 Spent Remaining Cash
(21:49) 5.6 Sold All My Stocks
(22:09) 5.7 Fell Behind on Mortgage(22:54) 6 STRUGGLING THROUGH RECOVERY
(23:05) 6.1 Tried Quitting Development
(23:33) 6.2 My Wife and I Found God
(26:11) 6.3 My Addicted Child Moved Out
(27:03) 6.4 I Started on YouTube
(28:32) 6.5 I Started Career Coaching
(30:43) 6.6 My Sleep Improved(32:01) 7 HOW BURNOUT CHANGED ME
(32:11) 7.1 Recovery is Daily
(32:31) 7.2 Confronted My Addiction
(33:09) 7.3 Became Aware of My Limits
(34:01) 7.4 Embraced My Suffering
(34:24) 7.5 Motivated By Change
(36:50) 7.6 I Began Tithing
(39:03) 7.7 Learning To Live Sober
(40:13) 7.7 Focus on The Positive
(41:09) 7.8 Reject Being Defined By Work
(43:56) Episode GrooveVisit me at JaymeEdwards.com
Find me on X as @jaymeedwards
Find me on Instagram as jayme.c.edwards
-
Trusting people is getting tougher than ever these days, and nobody seems to have a harder time than programmers and managers. In this episode, I'll teach you how to get some hard evidence to determine whether your manager is trustworthy or not. The goal is for you to find out YES and just have a healthy relationship with your manager.
But if there are trust issues, you'll have some tough decisions to make about your software development career. This episode can help anyone who has a boss on a software project (programmer, QA, DevOps, etc.), but since there are some unique ways programmers can have their trust broken by managers - I'll focus on that.
Get free access to TechRolepedia here:
https://jaymeedwards.com/access-techrolepedia/Download my free Career Guide here:
https://jaymeedwards.com/developer-career-guide/Need help with your career? Book a free career consultation:
https://jaymeedwards.com/services/software-development-coaching/You can also watch this episode on YouTube.
Chapter markers / timelinks:
(0:00) Introduction
(2:36) 1 WHY DON'T PROGRAMMERS TRUST MANAGERS?
(2:48) 1.1 Manager Can't Do What Programmers Can
(4:17) 1.2 Limited Visibility in Command and Control
(6:35) 1.3 Hearsay
(8:05) 1.4 Power Dynamics of Reporting to Someone(9:43) 2 WHY DON'T MANAGERS TRUST PROGRAMMERS?
(9:55) 2.1 Can't Comprehend All of Their Work
(11:01) 2.2 Past Bad Experiences
(12:26) 2.3 Remote Visibility Problems
(13:36) 2.4 Assumptions of Immaturity
(15:30) 2.5 Anxiety Due to High Cost(17:26) 3 HOW TO LEARN IF YOUR MANAGER IS TRUSTWORTHY
(17:41) 3.1 Micro-Commitments
(19:49) 3.2 Corroborate With Coworkers
(22:14) 3.3 Corroborate With "Skip Level" Boss
(24:55) 3.4 Set and Track Measurable Objectives(27:48) Episode Groove
Visit me at JaymeEdwards.com
Find me on X as @jaymeedwards
Find me on Instagram as jayme.c.edwards
-
Just the name Tech Lead has this kind of prestigious ring to it, and if you're like most programmers you might think it's the job to shoot for. But 20 years of my career have been spent leading software teams, and you might be surprised to know that tech lead is actually the worst job for most programmers!
Some of the information in this episode applies to IT professionals in any technical leadership role: whether that be leading programmers, UX, DevOps, QA - or any other discipline related to software development. But several of the points are more specific to programming leadership.
Get free access to TechRolepedia here:
https://jaymeedwards.com/access-techrolepedia/Download my free Career Guide here:
https://jaymeedwards.com/developer-career-guide/Need help with your career? Book a free career consultation:
https://jaymeedwards.com/services/software-development-coaching/You can also watch this episode on YouTube.
Chapter markers / timelinks:
(0:00) Introduction
(1:20) 1 TECH LEAD MYTHS
(1:29) 1.1 Smartest Team Member
(2:11) 1.2 Writes The Best Code
(2:59) 1.3 Chooses Key Technologies
(3:45) 1.4 Most Highly Compensated
(4:12) 1.5 Motivates Through High Standards(5:19) 2 WHAT SHOULD A TECH LEAD DO?
(5:22) 2.1 Improve Team Effectiveness
(6:35) 2.2 Defend Team Members
(7:52) 2.3 Congratulate Team Publicly
(9:00) 2.4 Getting Team Consensus
(10:19) 2.5 Help When Things Get Hard(12:57) 3 HOW BAD TECH LEADS GET PROMOTED
(13:28) 3.1 Strong Individual Contributor
(14:13) 3.2 Company Promotes Out Of Fear
(15:01) 3.3 Management Misunderstands Role
(15:25) 3.4 No Desire To Lead(16:15) 4 BECOMING A TECH LEAD
(16:34) 4.1 Practice Defending Your Team
(18:19) 4.2 Practice Congratulating Team
(19:30) 4.3 Read Books on Leadership
(20:46) 4.4 Work Closely With Others
(21:52) 4.5 Learn More About the Business(23:28) Episode Groove
Visit me at JaymeEdwards.com
Find me on X as @jaymeedwards
Find me on Instagram as jayme.c.edwards
-
As programmers, we often follow practices because of hidden desires - and "self-documenting code" is chief among them. In this episode I'd like to share some of the tradeoffs and implications of choosing to add comments to your code or not, to help you make the best decision for your software development career. When I first started developing software 25 years ago, the company I worked at mostly used C++ with a little Visual Basic and Java. At that time, all the other software engineers I worked with added comments to their code. And at the next two software product companies I worked for, programmers also chose to add source code comments as a regular practice. But once I moved to Austin, Texas 15 years ago and got my first job as an IT consultant I noticed something interesting. None of the other programmers on my team added ANY comments to their code! When I asked them about this, they would often say "the client is paying for features, not comments". I didn't find this a very acceptable reason for not adding comments to code, but I did my best to play along. Around this time the popular programming practice of "self-documenting code" first showed up on my radar. The idea being if we write our code with a clear enough intent, but using business terms and clean designs for the software we write, comments are unnecessary. But upon closer inspection I found this to be (in my opinion) wishful thinking rooted in laziness, upon a host of other factors. I hope this episode helps you make an informed decision about whether the benefits of code comments are worth writing them, or whether you should continue to practice self-documenting code as a principle. I believe we can have the best of both worlds: well-written code that reflects the business domain and is simpler to read, but with accompanying comments to reduce the time it takes for our software development team to use the APIs, helper classes, and other functionality our code and libraries provide.
You can also watch this episode on YouTube.
Chapter markers / timelinks:
02:50 Why Practice "Self-Documenting" Code? 02:56 #1 Laziness 04:43 #2 Reduce Visual Clutter 05:43 #3 Refactoring Burden 06:39 #4 Overconfidence in Simplicity 07:56 6 Benefits to Commenting 08:03 #1 Reduce Comprehension Effort 08:50 #2 Accelerate Business Understanding 09:50 #3 Use Comment Features in Editor 11:03 #4 Surface Code Behavior 12:07 #5 Additional Documentation Opportunities 12:48 #6 Treat Code Like a Product 13:51 Episode GrooveVisit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
Ever wanted to do something new, or make a change on your software project - but other people on your team won't support you? Maybe you want to move from scrum to kanban, use a newer JavaScript framework like remix, or if you're a UX designer introduce something like customer journey maps.
It would be nice to always have support from other people, but if you've never had pushback for one of your ideas, it's a matter of WHEN - not IF. So at some point, unless you want to quit your job every time you need a change to keep delivering great software, you'll need to persuade other people on your software team, or in management - to support you.
In this episode I'd like to share with you what I learned over 15 years of software development consulting about persuading IT management and other technologists on your software team. Persuasion is a soft skill that is more valuable than many people realize!
You can also watch this episode on YouTube.
Chapter markers / timelinks:
0:00 Introduction 1:13 10 Steps to Persuade Others 1:21 #1 Be Honest About Your Skills 1:57 #2 Have an Authentic Relationship 3:40 #3 Know How To Measure Success 4:43 #4 Identify Benefits To Others 5:44 #5 Incremental Persuasion 7:00 #6 Create Visual Aids and Assets 8:38 #7 Future-Pace The Benefits 9:53 #8 Know How They're Measured 11:08 #9 Timebox The Response for Support 12:29 #10 Practice Persuasion 13:39 #11 Episode GrooveVisit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
Many software development teams use an agile backlog but have NO business agility - and are actually using scrum with a waterfall mindset! When the product backlog is used on a scrum project and the business doesn't really understand agile, it wastes money and makes most programmers feel miserable!
In this episode, I share what I've learned about using agile methods with software teams that actually produces business agility. Business agility is the ability for a company building a software product to adapt to feedback and data gathered about how customers are using it. Since software development is such an unpredictable engineering activity, a business can choose to put their hopes in estimates, or deliver releases more often and let data be their guide.
I hope this episode helps you understand how programmers, product owners, scrum masters, and everyone else who works together to build and release software can do it in a healthy way - where less stress is placed on everyone trying to predict the future through estimates. Instead, we can use the insights gathered through feedback and recording data in production about how customers are using the software to product the RIGHT features - and at a sustainable pace!
You can also watch this episode on YouTube.
Chapter markers / timelinks:
0:00 Introduction 0:57 The Purpose of a Backlog 1:19 7 Waterfall Backlog Signs 1:28 #1 No Feature Usage Metrics 2:09 #2 No Release After Sprint 2:55 #3 Backlog Never Reordered 3:37 #4 Features Never Removed 4:19 #5 No New Features 4:54 #6 Estimates For All Stories 5:35 #7 Measuring Output Not Outcomes 6:32 7 Ways To Get Backlog Agility 6:53 #1 Measure Feature Impact 7:51 #2 Release Every Sprint 8:51 #3 Don't Build Onto Features 10:08 #4 Use Data To Reprioritize 10:42 #5 Remove Bad Features 11:28 #6 Commit To Outcomes 12:40 #7 Use Cross-Functional Teams 15:25 Episode GrooveVisit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
When programmers are forced to estimate code on software projects and they turn out wrong, who's to blame? Are there other reasons why estimating software development projects are so hard, that are outside the control of each programmer?
In this episode, I share some of the unique properties of estimating code, and why programming estimates are different than many other types of work. Most of it boils down to treating software development like manufacturing, which is a repeatable process that doesn't involve as much teamwork. Programming on the other hand, is usually done on a team. And to meet the commitment forecasted by our estimate, we need help from other developers.
There are also complexities to our work that make estimating increased the chance that things go bad that are a symptom of misunderstanding the nature of programming by project managers, product managers, and scrum masters at some companies. They need help from software developers to understand why the number of variables increases the chance that estimates turn out bad, and that the degree of things being wrong can have disastrous consequences for business commitments that relied on estimates.
You can also watch this episode on YouTube.
Chapter markers / timelinks:
0:00 Introduction 1:19 Why Programming Is Unreliable 1:26 #1 Not Repeatable 2:06 #2 Too Many Variables 2:50 #3 Surface Understanding 4:06 #4 Unique Integration 4:59 #5 Low Diagnostic Output 6:08 #6 Knowledge Work Mismatch 7:19 #7 Undervalued Teamwork 8:20 Reduce Impact of Bad Estimates 8:42 #1 Reduce Estimated Work 10:06 #2 Keep Estimates With Estimators 11:26 #3 Estimate In Components 12:50 #4 Choose Familiar Technologies 13:56 #5 Find Native Integrations 15:04 #6 Stop Using Estimates 16:10 Episode GrooveVisit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
Every programmer seems to want to vomit the second they hear the word scrum. What is it about scrum that's made programmers hate coding so much, and how can you prevent this on your software development team
In this episode, I share 7 reasons why programmers hate scrum, and how it makes our jobs nearly impossible on software projects where the scrum master, product owner (or product manager), and the rest of the software company use it to abuse programmers. These mostly get down to not understanding the scrum guide, and human nature!
In this first section of the video, I explain how management on scrum projects usually focus on speed and visible features to the point that it puts the quality of the product at risk. They treat story points like time. They resist investment in things like improved architecture, testing, deployment, and the other things needed to keep developers from quitting unless kept in check. And they fail to accept reality when bad user stories, missing acceptance criteria, and abuse of the burn down chart (and velocity metrics) turns scrum into a numbers game instead of about delivering a quality software product.
In the second section of the video, I share 7 practical tips for changes you can make on your software team to start loving scrum again! If programmers on your team hate scrum, drawing clear lines between what software developers and project managers, product managers, product owners, or scrum masters can and can't make decisions about is essential. But as programmers, we also need to be more diligent with how we follow scrum processes. We need to closely inspect the work and only move forward with 100% acceptance criteria. We can't make commitments to vague user stories. And we have to stop estimating just for programming and include time for all the things we know we need - QA, automated testing, automated deployment, infrastructure as code, software architecture - basically all the goodies that keep a project on track as it grows in complexity. This is how modern teams do continuous delivery and devops.
I hope this episode gives you some good things to think about. Scrum is a complicated topic, but following everything exactly by the scrum guide is a slippery slope. To love scrum again, programmers need to work with management and the rest of the company to adapt processes to meet the way everyone needs to work together to deliver software. And that's different for every team!
You can also watch this video on YouTube.
Chapter markers / timelinks
0:00 Introduction 0:36 7 Reasons Why Programmers Hate Scrum 0:58 #1 PO in Daily Stand-Up 1:36 #2 Overstepping Scrum Master 2:15 #3 Obsession With Features 3:38 #4 Story Points Treated As Time 4:42 #5 Refusal To Cancel Sprint 5:58 #6 No Acceptance Criteria 7:19 #7 Burn-Down Chart Used To Blame 7:54 7 Ways To Love Scrum Again 8:16 #1 Remove PO From Daily Stand-Up 9:00 #2 Put Scrum Master In Their Place 9:49 #3 Buffer Estimates For Code Quality 11:03 #4 Don't Commit To Multiple Sprints 12:04 #5 Keep The Burn-Down Chart With Developers 13:00 #6 100% Acceptance Criteria 13:52 #7 Deliver Features That Delight 15:16 Episode GrooveVisit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
Professional habits are what makes the difference between someone who actually writes code like a senior programmer - and wishful thinking. The syntax and patterns you use on software projects don't matter nearly as much as the standards you hold yourself to for professionalism.
In this episode, I share the essential habits I've developed while working on nearly software projects over my career. If you want to write code like senior programmers do, I hope these practices help you stand out from the pack.
6 HABITS FOR WRITING CODE LIKE A SENIOR PROGRAMMER
The first habit is to finish the code you start! There's immense pressure on some scrum or kanban projects to show progress, but if you aren't done - don't lie about it! This only leads to more personal technical debt that you will be under more stress to finish later. If you don't want to let the code grow out of control - this is completely up to you.
The second habit is to enforce coding standards. If other programmers on your team have different preferences for how they like to format curly braces, spacing, or any other aspect of your code - this makes it frustrating to share code across the project. We've got the tools to do this automatically now - use them!
The third habit is to be disciplined about documenting the patterns the team has agreed to use. You absolutely must have a wiki topic or markdown file in your project that has links to how to apply every major pattern on your project. If you do this, it reduces wasted time in code reviews, and prevents people from introducing new patterns without a justifiable reason for having a discussion before it permeates throughout the codebase.
The fourth habit is to review new coding patterns with your team as soon as you introduce them. Rather than replace an existing pattern all over the code base (ask for forgiveness rather than permission), do your teammates a solid and be inclusive as soon as you have something to show. They'll probably have good advice for how to improve on your use of it, and you can get their buy-in and enlist them to help you with the full refactoring effort.
The fifth habit is to NEVER expose refactoring as tasks, user stories, or tickets in jira, github issues, trello, asana, visual studio online - or whatever tool your team may be using for work tracking. Whenever an essential engineering practice is called out as a separate item - it only tempts management to pull it out.
And the sixth and final habit is to always assume there will be unexpected change in the project for every task you need to estimate. Whether it's unplanned software design meetings, troubleshooting, or documentation - to write code like senior programmers actually do, you can't be pressured to cut corners. While we can't predict every possible uncertainty on a software project, if you estimate like nothing will go wrong - it's your own fault.
You can also watch this video on the YouTube channel.
Chapter markers / timelinks
0:00 Introduction
0:25 Why senior code matters
0:30 1. Team comprehension
0:57 2. Reduce interruptions
1:28 3. Extend longevity of code
2:10 6 habits of senior programmers
2:18 1. Prevent unfinished work
3:46 2. Enforce coding standards
5:11 3. Document chosen patterns
8:01 4. Review new patterns early
9:28 5. Never expose refactoring
11:16 6. Assume unexpected change
12:40 Episode groove
Visit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
I thought I knew what developers needed, but then I met over 200 people online to learn what unlocks their career. The results were surprising in some ways, and not in others.
The first thing I learned was that having a plan for your career in software development is something programmers aren't getting enough help with. When I would need a new job, I often took the first reasonable offer instead of having more purpose. It seems other developers are treating their career the same way.
The second thing I learned was that developers need more help getting a new job. They treat LinkedIn like an online resume when it's not. LinkedIn is a social profile for your career in software! Software engineers, programmers, data scientists, and other types of developers often have too many languages and technologies on their resume over time - and this bleeds into LinkedIn. I like to help them redo their profile to be more focused on their human side - and learn better techniques for networking to find the best job.
The third thing I learned was that developers are suffering from burnout in their career in droves. I've actually had a company pay me to help their lead developer recover from burnout! Recovering from burnout is more than a better diet, exercise, or having a therapist - though people who come to me for help with burnout often already have one. You need help with setting healthy boundaries with your employer so you can be a healthy software developer!
The fourth thing I learned unlocks the career of IT professionals in software development and engineering jobs is earning respect and getting recognition from their colleagues. Sometimes there's a difficult person they're dealing with who's a narcissist or just has unrealistic expectations. I use some of the techniques I've learned in IT consulting to help them appeal to the desires of the person they're frustrated with. Once they start earning trust and resetting expectations - rewards and promotions should follow!
The fifth thing I learned developers really need to unlock their career is becoming more common. Most of the over 200 I met online were at least considering going into freelancing or IT consulting as a way to work for themselves. Showing developers that the paperwork and administrative tasks needed aren't as bad as they think is something I love to do. I would never go back to being an employee unless I had to at this point. I love being able to pick my own IT consulting clients.
The sixth and final thing I learned developers really need in their career is to start using a new tech stack, cloud or data science platform, devops technologies, or maybe switching from a business analyst or product management gig into being a scrum master. Don't hit the books, and waste time on algorithm crunching sites like Hackerrank and Leetcode. Build confidence through having a better relationship with people who might interview you, and have great examples of work. Are there things you're struggling with in your software development career that don't fit into these 6? Leave me a comment! My career purpose is to help more people be healthy software developers.
You can also watch this episode on YouTube.
Episode timelinks:
0:00 Introduction
0:37 Have a Career Plan
2:09 Get a Better Job
5:31 Stop Burning Out
5:55 Earn Respect and Recognition
8:45 Work for Myself
11:17 Use New Skills or TechnologyVisit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
It's tempting to compare yourself to other developers or take skill assessments to see how you measure up, but honestly it's impossible to truly know if you're a good programmer!
In this video I share what I've learned over my 25 year career as a programmer, software architect, and consultant that I hope reduces any anxiety you may have around your self worth.
To start this off: why do we even care if we're good programmer?
Well first of all, the people who depend on us to do a good job as a developer need to know we're competent and can get the job done. Basically our coworkers have expectations, and we want to meet them.
The second main reason I see people caring how good they are, and is the bigger focus of this episode, is comparing themselves to others! With social media (especially LinkedIn) and other influential people showing off their accomplishments, we often wonder how we measure up. But that's a dangerous game.
How do we try to assess how good of programmers we are?
The first way is skill assessments like tests, bootcamp outcomes, certifications etc. And while these can help, I don't put much stock in them. They usually have a very focused and narrow view.
The second way is looking at what we've accomplished in our career as programmers. Have we produced good output for the company? Have we been able to get features out in a reasonable time?
The third way is getting feedback! While performance reviews can help, asking another developer, manager, or another trusted professional for explicit feedback is a great way to find out.
There are two reasons why I don't believe we can really know how good we are.
The first is that we don't have a standard definition of what makes a good programmer. There are so many skills we need! Coding, testing, DevOps, wiki topics, scrum, kanban, data science - it's crazy. And that's only the technical and process stuff. There are also all of our personality traits like openness, coachability, motivation and such.
The second reason why we can't really know how good we are is based on the Dunning-Kruger effect. I left a link below where you can read more about it. But it explains what I experienced in my career. That I went through a progression of growing confidence until I realized my own incompetence, then had to build it all over again.
We go through these cycles of high and low confidence uniquely for every skill we use as a programmer! So be kind to yourself. It's practically impossible to know how good you are, because we're all different, and we're all growing different skills at different times!
You can also watch this episode on YouTube.
Episode timelinks:
0:00 Introduction
0:35 Why Care If We're Good?
0:39 Reason #1: Confidence
0:50 Reason #2: We're Comparing Ourselves
1:17 How Do We Evaluate Skill?
1:23 Eval Approach #1: Assessments
2:15 Eval Approach #2: Accomplishments
2:48 Eval Approach #3: Feedback
3:39 Why Can't I Know???
3:58 Reason #1: No Standard
6:10 Reason #2: Warped Self-Image
8:00 The Dunning-Kruger Effect
10:15 Having Realistic Expectations
11:20 Every Skill Grows at a Different Pace
12:52 Next Time
13:33 Episode GrooveVisit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
The first software project of my career was a masterclass in surviving corporate politics that I'll never forget. Programming was the least of my problems! The perfect storm of addiction, deceit, and surviving a death in the family sent me into a downward spiral on this true story of a software project. In this story, I share the personal details of how my struggles with marijuana addiction and the lies of IT leadership collided. Looking back at this software project in the context of my career, I can see how it shaped me. No programming degree or bootcamp could have prepared me for working in software development would really be like when powerful people were involved. As a result of this experience, I went through a period of not trusting anyone, and learning to be vulnerable again took decades. But it also taught me some important lessons about loyalty, perseverance, and putting work/life balance in perspective. I hope by sharing this story, I can encourage you to take some responsibility for your own actions while coding. While at the same time being alert to the evil tactics people can threaten you with when ego, power, and money are on the line.
You can also watch this episode on YouTube.
Episode timelinks:
0:00 Introduction
1:10 The Calm Before The Storm
2:07 A Fragmented User Experience
3:00 Boredom Births and Idea
3:50 An Unexpected Demo
5:45 Mutiny In The Ranks
6:19 The Replatform Distraction
6:55 The Mutiny Exposed
7:50 The Confusions of Addiction
8:55 Impending Family Tragedy
9:41 The Burden of Responsibility
10:31 Putting Life Before Work
11:50 Comparmentalizing Grief
13:02 Accusations of Incompetence
13:50 Investigating the Truth
14:34 Relieved - But Not Really...
15:12 Act II: The Downward Spiral
15:47 A Foreshadowing Warning
16:53 A Seemingly Standard Practice...
17:41 Signs of Sabotage
18:34 The Deception Sinks In
19:44 A Coup D`Etat
20:57 A Harsh Lesson in Project Politics
21:17 New Leadership Arrives
21:38 Unrealistic Expectations
22:33 Mission Impossible
23:45 A Last Ditch C@ckblock
24:27 An Unjust Casualty
25:16 Conclusions
27:41 Next Time
28:17 Episode GrooveVisit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
There are tons of people online telling you how to get a better career in software development. Unfortunately, they usually tell you a fluffy story that glosses over the truth. In this episode, I share the 4 career desires of every software developer. This is a concept I discovered through career coaching other people in tech positions (developers, product managers, DevOps, data science, etc.) over the past 3 years. An important thing to know about these desires is that they change over our lives. What I wanted from my career in my 20s, was very different in my early 30s, and then in my 40s. This isn't specific to your age per se - it's more about being aware of your changing life situation. I got myself into a lot of trouble in my software development career when I was pursuing the wrong career desires. The first desire is impact. This is the feeling that the work you do makes a difference! Not feeling like you're making an impact can be either because you aren't able to use the skills you want, or the mission of the company doesn't inspire you. The second desire is growth. This is acquiring new skills to increase your value in the marketplace and get to do more different things on the job. These don't just need to be technical skills like programming however. There are also the skills of persuasion, communication, leadership, negotiation - or anything else that makes us more effective in our software development career. The third desire is work/life balance. This is the whole reason I made the healthy software developer YouTube channel in the first place! If you're having trouble sleeping, no energy to exercise, no time for your spouse, kids, or friends, and you spend almost no time pursuing your dreams - you're burned out! I suffered from serious career burnout as I've discussed in many other videos. Don't let this happen to you!
The fourth and final desire, is rewards (or benefits). While the things we do on software projects can be fun, to have a career we need to be compensated well for our efforts. However rewards like getting to work with someone you look up to, flexible hours, stock options, key opportunities that lead to others in the future area also benefits.
The perfect job would be one where you're making a big impact, acquiring lots of new skills, have a healthy work/life balance, and incredible rewards. I tell people this software development job doesn't exist! These 4 career desires oppose each other.
To get more work/life balance, you may need to sacrifice pay, or impact at times. To get an opportunity to have a bigger impact on a software project, you may need to grow less and use the skills you're already really great at. The important point is to not expect the same level of growth in all 4 of these career desires.
You can also watch this episode on YouTube.
Episode timelinks:
00:00 Introduction
00:55 The 4 Developer Career Desires
01:28 The Desires Change Over Time
03:03 Desire 1: Impact
05:22 Desire 2: Growth
07:11 Desire 3: Work/Life Balance
08:56 Desire 4: Rewards
10:41 The Perfect Job That Doesn't Exist
11:22 The 4 Desires Oppose Each Other
12:18 Pursuing A Desire Is A Tradeoff
12:55 A Call To Action!
13:31 Next Time...
13:44 Episode GrooveVisit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
Are you looking around on your software project and just waiting to see someone fail? Are you quick to condemn a manager or developer and cast them useless after a single mistake? Today we’re going to talk about how canceling developers and other IT professionals for mistakes can hold you back from the career you want in software. When I first began developing software, I wasn't particularly ambitious. I needed to make a living to support my wife and son, but I came from a background of partying and playing in a band. But after a few short years I had several promotions and raises, and it started to go to my head. With each new success, my pride got bigger. Once software projects started getting complicated, I started looking for people to blame. The scrum master didn't understand agile enough. The operations team wasn't making it easy enough to release changes into production. The other developers weren't following my coding patterns. Yeah, I became an elitist jerk. But as I've told you many times on this channel, I fell hard eventually. A victim of career-long burnout, I lost my job, a lot of money, and sunk into depression. But when I came out of it, I made this channel and started giving software developers and engineers career advice. It also led me to learn how to work better myself - and help you be a healthy software developer.
A moment though of reflection for yourself: are you on the way there? Starting to get rewards and recognition for developing software? Is it getting easier to see flaws in developers and other people on your software project, making you quick to judge? Are you canceling the people who can help you for simple mistakes?
If we're humble and honest, we've all made mistakes. And I'm sure I'm going to make many more, whether on a software project, coaching you on your career, or on this channel. I'm pretty sure if you're willing to take an honest look at yourself, you know you're going to too. But you've made mistakes in the past and been forgiven. So should you be more forgiving too? Can we really be fair canceling anyone?
What would it be like if all our teams were more like this? What if we worked together assuming we'll make mistakes, and not being surprised? What if we spent more time forgiving, learning, and teaching - and less blaming? Imagine the courage we could have to try and do risky things that might be breakthroughs with our products, technologies, and careers?
You can also watch this episode on YouTube.
Episode timelinks:
0:00 Introduction
2:35 The Dangers of Leading
4:35 Falling Hard
6:14 Is Success Putting You in Danger?
8:15 Motivation for True Forgiveness
9:20 Leading Means Helping!
11:00 For Future Leaders...
12:52 What Could Teamwork Be Like?
13:48 Why Should You Care?
14:30 A Call To Action!!!
17:40 Next Time...
19:25 Episode GrooveVisit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
Can you believe it's been 3 years since I made an episode? Yeah you can - you've been asking me to come back. Sorry! I just wasn't ready yet. I got clean from marijuana addiction in 2019 but it's taken me a lot longer than I'd hoped to get better. At least better enough to come back on YouTube. In the meantime, I've met with about 200 people all over the world to learn better how to help you with software development career issues. There were a lot of things I thought I understood. And some of them I did. But it was humbling to realize many problems you're having with your career are forcing me to step up and learn again.
You may notice this video looks different! I've collected some gear over Craigslist and whatnot to try and create a more interesting look for our time together. I hope you like it. I'll be tweaking it over time as I make more videos about Healthy Software Development.
I should mention, thank you for blowing up my channel over a year ago! The video "Why do so many programmers lose hope?" got recommended by a well known programming channel and within a short period, the channel grew 10x! I'm not someone who believes the number of subscribers determines the value of content, but it sure helps me to know you care.
In the next episode, I'll be talking about learning from people who've made mistakes. Chief among them - me! I see a real problem in our culture right now with developers and other people in IT only looking to people with a fake persona of having all the answers or being flawless.
You can also watch this episode on YouTube.
Episode timelinks:
00:00 Introduction
01:33 Where I've been
02:44 I'm still having health challenges
03:55 The channel purpose hasn't changed 04:48 I'm career coaching now
07:30 I'll focus on career outcomes that work 09:45 Channel production changes
09:51 The channel blew up 10x!
11:40 Thank you for your support
13:13 The next video is about...Visit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
I've been working through anger issues after reflecting on the content I've put out there for people in the software industry.
I mostly avoided social media for the past 5-8 years and when I started putting my ideas out there, I bought into the "outrage culture". I also have been on many failed projects. And I've had personal problems with my family and identity.
I made this video to apologize for my anger and how I've come across as "knowing everything" sometimes. I don't think it helps anyone to be another voice in this, and so I'm committing from here on out to be more discerning with how I share my opinions and advice.
When I was 14, I stopped going to church because I wanted to party with my friends. 5 years later I got my girlfriend pregnant and had a really hard time with being a father. I felt too young in public, frustrated with myself and my bad decisions, and so I began to smoke marijuana pretty regularly after work.
After my Dad died from cancer, I didn't understand how to cope with the grief and so I used video games (MMOs at the time), music, and pot to escape from what my life had become. Though from the perspective of people I worked with I was successful, my home life was a mess.
Software developers make a lot of money and even though I had most of my financial and material needs met, I was really empty inside. After suffering from a bout of chronic insomnia two years ago, I began going back to church.
It was really strange and I felt completely out of place. But after I started going to a men's group offered by the church on Fridays, I met several other men who were open about their failures and willing to counsel me where I'd went wrong.
I began praying that God would help me with a lot of things, but 3 in particular kept coming up. First, that I would have the courage to do what's right even when people don't like me. Second, that I would heal from bitterness in my life, and that my heart would soften to let go of anger. And third, that I would have more discernment to make decisions that would be better for my life.
My life has been going much better in all areas other than my career. I've decided to go into management after reflecting on where my passions are with helping companies and people be more healthy about how they develop software.
What this means for the channel is that I'll continue to make content, but I need to do it in a more sustainable way. I need to focus more on my personal responsibilities, and healing from burnout on projects.
I've started writing songs again to try and provide myself with a better creative outlet. It can be really frustrating to work at companies when they put you in a box and don't allow really good work to be done. I was looking for the opportunity for creativity in the wrong place in my life.
Thank you for being so supportive over the past 2 years of me doing this. I just wanted to help people avoid the mistakes I've made, and I never thought there were so many other people out there who needed help too!
You can also watch this episode on YouTube.
Related resources:
Are You A Perfectionist Programmer? The De-Corporatization Of Jayme Software Project Stories (Playlist) Is It Safe To Make Mistakes On Your Software Project? Colin Zera - Sister (Home Acoustic Video) My Software Developer Career Journey (Playlist) Why Do So Many Programmers Lose Hope? Can You Be Agile When Your Company Isn't? What MEN Need To Know About Software Developer BRO CULTURE! Why Do Some Programmers Never Agree?Visit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
Scott Nimrod is an experienced Software Consultant based out of Miami who specializes in Test Automation, WPF, Functional Programming, and a variety of other technologies.
In this interview, Scott and I discuss the balance between strengthening your reputation through your personal brand as a developer, and the teamwork necessary to be successful in your career.
We also touch on concepts in the interview with Woody Zuill about mob programming and the "noestimates" movement.
Scott also runs a YouTube channel with great interviews and live programming exercises.
You can also watch this episode on YouTube.
Related resources:
Woody Zuill on Mob Programming and Influencing Change How Agile Teams Grow Toxic! Ep. 4 Commitments
Scott Nimrod on Consulting and Software Craftsmanship How to Disagree With Your Manager Respectfully How Agile Teams Grow Toxic! Ep. 3 ForecastingVisit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
-
Today I have a special guest, Woody Zuill, who's one of the leading voices in our industry around the concept of Mob Programming.
If this is the first time you've heard of it, Mob Programming is essentially an entire team working together with only one person's hands on the keyboard.
There are some surprising advantages to this approach that you may not have encountered before.
Follow Woody on twitter at https://twitter.com/woodyzuill.
Watch the video and access resources related to this episode on my website: https://bit.ly/2RQLOeB
- Visa fler
