In general, don’t feel like your project needs to be perfect from the ground up or follow every best practice since many of the best practices can and do contradict one another if you don’t know how to choose between them effectively you can hit a pitfall early of trying to adhere to all of them. Every software project is an evolution. A perfect solution at two years it might be terrible for year one or the first six months, and a great solution for year two may be terrible at year five.
Also, don’t think in terms of pitfalls, most software “pitfalls” are sane a logical responses to requirements at the time and worked at the time, but then needed to be heavily changed when the requirements of the project shifted in a completely different way than you ever expected.
Building a successful project is kinda like trying to find a store in a city, you think you know where the store is and you have an address, but when you arrive at the location you thought it was in the sign on the door that says they moved the store across the city to another location and you should have gone the opposite way three turns ago. Was it a mistake? Or did you need to make that choice in order to find out you had to drive the other direction? It’s really about how you respond to this kind new information that determines if your project is a success. Success is a moving target and changes depending on the day and month for almost every project I’ve ever worked on. very few are so constrained that they have a hard set finish with success or failure.
So I will say this, working software that gets the job done is far superior to perfect software that never makes it to production. Not to say you shouldn’t worry about code quality or about fixing bad habits, but those things come with time and won’t be solved with one conversation, blog/forum post, or reading a single book.
My advice is to ask targeted questions when you feel the frustration of a “pitfall”. If you start to get frustrated realize it’s not something you have to do in silence and reach out. I’ve been programming for nearly a decade now, and I still run into instances where I chose wrong originally and have to do a lot of work to change the direction of the code. There really is no way to avoid all pitfalls or bad choices from the start they’re all pretty much just trade-offs. If you manage to figure it out you will make billions selling it to every single software company on the planet.
So that all being said if you ever need help I’m usually on the elixir slack, and usually available for a skype call, and would be happy to help.
