--Originally published at Rudy's Corner
This will be my list of the 30 out of the 97 that I felt most identified, if you want to read all 97 here is the link of the book.
So, let’s begin
1) Don’t put your resume ahead of the requirements
This first one is kinda obvious (most of them are tbh) but not really. The important thing to underline here is that it is more important to use the technology that fits better the user, even if it is not the most challenging, it is better to have something that works perfectly done with an “easy” technology that doesn’t look that good on your resume, than something complicated that looks “pretty” on your resume.
At the end of the day, it is way better for your career to have happy costumers, than an “impressive” CV. I mean, if you have happy costumers, they might tell their friends about you, and before you know it, you have more work and a better reputation.
2) Chances are, your biggest problem isn’t technical
It is very easy to blame the technical aspect when a project fails, buuuuuut in most cases it didn’t fail because of it, it failed because of the people that were involved in such project. Because, well, people are what make the project and if you can’t communicate with the ones that are not performing as well as the others, then your project will probably fail. Conversations are key, and that’s what I’ll talk about next.
3) Communication is king; clarity and leadership its humble servants
To have a good communication between the Software Architect and the Developers, the first thing to do is be there, with them, don’t sit on top of the tower, as if you were more than them. Next, you will need to use clarity