Healthy Developer

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.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Chapter markers / timelinks:

(00:00) Introduction(01:19) 1. Why Programming Is Unreliable(01:26) 1.1 Not Repeatable(02:06) 1.2 Too Many Variables(02:50) 1.3 Surface Understanding(04:06) 1.4 Unique Integration(04:59) 1.5 Low Diagnostic Output(06:08) 1.6 Knowledge Work Mismatch(07:19) 1.7 Undervalued Teamwork(08:20) 2. Reduce Impact of Bad Estimates(08:42) 2.1 Reduce Estimated Work(10:06) 2.2 Keep Estimates With Estimators(11:26) 2.3 Estimate In Components(12:50) 2.4 Choose Familiar Technologies(13:56) 2.5 Find Native Integrations(15:04) 2.6 Stop Using Estimates(16:10) Episode Groove

Visit me at thrivingtechnologist.com

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!

Work with me: https://healthydeveloper.com

Chapter markers / timelinks

(00:00) Introduction(00:36) 1. 7 Reasons Why Programmers Hate Scrum(00:58) 1.1 PO in Daily Stand-Up(01:36) 1.2 Overstepping Scrum Master(02:15) 1.3 Obsession With Features(03:38) 1.4 Story Points Treated As Time(04:42) 1.5 Refusal To Cancel Sprint(05:48) 1.6 No Acceptance Criteria(07:19) 1.7 Burn-Down Chart Used To Blame(07:54) 2. 7 Ways To Love Scrum Again(08:16) 2.1 Remove PO From Daily Stand-Up(09:00) 2.2 Put Scrum Master In Their Place(09:49) 2.3 Buffer Estimates For Code Quality(11:03) 2.4 Don't Commit To Multiple Sprints(12:04) 2.5 Keep The Burn-Down Chart With Developers(13:00) 2.6 100% Acceptance Criteria(13:52) 2.7 Deliver Features That Delight(15:16) Episode Groove

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.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this video on the YouTube channel.

Chapter markers / timelinks

(00:00) Introduction(00:25) Why senior code matters(00:30) 1. Team comprehension(00:57) 2. Reduce interruptions(01:28) 3. Extend longevity of code(02:10) 6 habits of senior programmers(02:18) 1. Prevent unfinished work(03:46) 2. Enforce coding standards(05:11) 3. Document chosen patterns(08:11) 4. Review new patterns early(09:28) 5. Never expose refactoring(11:16) 6. Assume unexpected change(12:40) Episode groove

Visit me at thrivingtechnologist.com

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.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

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 Technology

Visit me at thrivingtechnologist.com

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!

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

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 Groove

Visit me at thrivingtechnologist.com

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.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

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 Groove

Visit me at thrivingtechnologist.com

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.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

CHAPTER MARKERS

(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 Groove

Visit me at thrivingtechnologist.com

Get your tech career unstuck here: https://healthydeveloper.com/coaching

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?

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 Groove

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.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

CHAPTER MARKERS (0: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 thrivingtechnologist.com

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!

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Related resources:

• Colin Zera - Sister (Home Acoustic Video)

Visit me at thrivingtechnologist.com