Was going to tweet about this but @afilina beat me to it 😅

It's often just what we would call "fundamentals" that make the difference.

When I think about programmers I've worked with that I consider "good" and "bad"...(keep reading)

#SoftwareEngineer #softwaredevelopment

https://twitter.com/afilina/status/1263835308610719749

The "good" ones aren't super-geniuses. They simply have the basics down:

- Small objects
- Small methods
- Change together... stay together
- Test it!!!
- Different logical concepts should be different pieces of code (even if named the same...)
- Immutable objects + funcs

Don't do too much #software design upfront. But, you also want to be intelligent about laying a foundation for the needs of the business.

Some of the questions you might want to consider at the beginning of a new product or project:

#SoftwareEngineer #SoftwareDeveloper - Should the system be structured in a way that reflects the business divisions in the current organizational structure?

- Should your software system be structured in a new way?

Microservices != Bounded contexts.

Ex. We might have BCs payments, shipping, warehouse, search, etc.

Payments + shipping *could* be part of a well organized monolith.

Warehouse and search could be independently deployed processes/services (thread)

#dddesign BCs are about conceptual boundaries that keep contextual language consistent inside it's own bubble, makes a specific problem+solution focused and easier to manage.

Domain-driven design can seem really complicated with lots of jargon, etc.

At-the-end-of-the-day, in a nutshell, it's a divide-and-conquer approach.

The #1 thing is to divide your business into smaller "chunks". Each chunk is easy to deal with + understand (thread) BUT, to be able to do that well and in a way that benefits the business, you need to understand....the business.

What are the moving parts of the business?

Who are the people?

What do they do? When do they do it? Why do they do it?

What are the processes?

Dev Tip 🔥: You want to convince management of something? (Tackling a certain problem area of your software code, issues with infrastructure, lack of team standards, etc.)

What do you do?

Tell a story. 🙂(Continued 👇) Don't start by writing out a huge technical document showing all the places in your code that need to be changed.

Dev Tip 🔥: Should you learn that next hot technology? Everyone's talking about it!

Will it really **transform** the way you make software and solve customer problems?

Sad news: Nope. Not _that_ much.

(Keeping reading for 30+ things that do! 👇) We are obsessed with learning about more tools and languages!

If your architecture is bad, you're solving the wrong problems, your client doesn't understand when you try to explain things... then shiny tools don't help.

And these are fundamental to your business' success!

Dev Tip 🔥: Figure out how and what you are being measured on by your company.

Instead of just doing your typical todo/task list, incorporate tasks or ideas that will move those metrics forward!

1/10 This also applies to your team.

How is your team success measured?

How can you help move those metrics ahead for the team?

Are there more group-like or communal activities that you can initiate that will help? (E.g Code reviews, training, sharing articles, etc.)

2/10

🔥 Dev Tip: I've seen this asked quite a bit on forums etc.

"What programming language should I learn next?"

Nodejs, JavaScript, PHP, MySQL, C#, Python, etc.?

What's my answer?

Thread continued 👇 These are just tools. It's like:
- A guitar to the guitarist
- A pen to the writer
- A hammer to the carpenter
- A car for the racecar driver

🔥(Senior) Dev Tip: Make devs 100% responsible for their contributions.

Did Fred push code that broke feature X? Rollback and tell Fred to fit it. He will learn to be more careful. He will learn to own his mistakes.

Keep going... 👇 Your team will grow most if they:
- Are given the ability to fail without being "whipped"
- Are given the ability to fail so they can adjust how bold their changes are
- Are noticed and acknowledged when they have success
- Can learn from other's mistakes (😉)

Keep going...👇

Thread for Junior Developers/Engineers:

Bad news - the ability to be a master/elite coder is only the first step in your career 😞

You'll soon find that coding is the easy part.

Some of the hard parts - if you want to progress as a software engineer/developer - are: 1. Being able to communicate clearly in business language - not tech jargon - with business people / non-technical co-workers.