Preface: I’m not sure if thise is the right place, because this is not direclty Elixir related… but I’ve always got some of the best advice from this community.
Current situation: Spinning wheels… false starts… moving way too slow trying to get a software project airborne.
Mission:
Get a broad spectrum, eagles eye overview of best development practices, tools, resources, systems, techniques, streamlining, optimisations, unspoken tricks & practices etc. used to produce some of the best code we’ve seen so far, complete with case studies of successful projects, case studies of unsuccessful projects.
On the other side of the deep dive, have enough of an understanding of the landscape that I can avoid the common pitfalls that cause software projects to fail… compressioning years into days.
I’ve largely been self-taught. From that, a lot of frustration, and I’m sure bad habits developed.
I want to expose those now. And move forward with a much stronger, broad spectrum grounding of not the details of coding, but more so, what it takes to make a software project successful, from start to finish.
I’d say get a few books. Look at the new Book Club section – people give really honest reviews and gists about the chapters.
As for general best practices, don’t tempt us. Some of us can talk about this for weeks. But IMO wisdom cannot be transferred to anyone with words alone; one has to have grown to understand the problem the wisdom solves in order to accept it. Not sure that any amount of explaining will help.
That being said: make a small project that you’re comfortable with it being public. Offer it for review here. You’ll get objective and constructive advice.
We can also start by asking you the question: what are the top 3 issues you believe are hampering you? Maybe you just have an impostor syndrome and you are actually really good.
I suggest you find ways to get in-person time with someone more experienced. That could involve pair programming at work, or maybe spending lunches with co-workers discussing technical topics. It might also help to get involved with local user groups. Via these techniques over my career I discovered people I could learn from and I’ve continued to keep in touch with them over decades.
I know you want to have all the knowledge/experience now, and your enthusiasm is laudable, but have some patience with yourself. It will take time. Start with solving concrete problems, then working to more general abstractions. Over time you’ll see connections between past problems you faced and a current problem and gain intuition on how to approach it.
That’s a lot of stuff
Avoiding pitfalls that cause software projects to fail: if you figure that out, you can make a lot of money with that.
As @gregvaughn said: have patience. And his other tips I definitely agree with.
I’ll add: you’re going to keep making “mistakes”, going into dead ends and “waste time”. But that is part of learning. When you learned to walk (assuming you can) falling was part of the process. There aren’t really any shortcuts.
Personally I always try to ask: what kind of learning is most effective (in this field)? What kind of learning works for me? And then work hard and smart at it.
There are plenty books and courses about software development. But software development tends to follow the same path:
planning
design
coding
testing
The twist is, there are plenty branches, schools of thoughts, opinions, and best practices on how to do these things. Computer science is natural, much like math, but when you add people into it, it becomes software engineering, it is so different, because there are people, people are different to each other.
Some people prefer doing the TDD, others not so.
Some people prefer doing daily stand-up, others not so.
Some people prefer using framework like scrum, others not so.
Even Agile itself (according to Martin Fowler) means no framework, no rule, just follow what team knows best.
Now, if you ask me what universally makes a software project to fail (in engineering point of view), I can make you a simple stupid list:
Code has no test, bugs and regressions emerge because tests are not enough.
Hard to read/navigate/understand code, when even your text editor complaints about it, it means your code is not healthy. Developers need extra energy on maintaining them, developers tend to require more time to do anything about it, and new onboarding developers will have difficulty on learning about them. This brings us to other topics like design pattern, object oriented programming and functional programming itself.
Hard to change/adapt code. Read below.
Unclear software requirements/specifications, this is the bottom of the Jenga, the earliest domino. In modern time like this, a lot of developers work in startups with fast-moving environment which probably means fast moving requirements. This directly correlates with above point with writing code that adapt to changes. Plenty of startups as the sprints goes on and on, have difficulty moving quickly because their codes are harder to maintain then before. I know this is not 100% developers responsibilty, so that’s why people create BDD, so we create a ‘bond’ with non-technical people to specify the requirements.
The first point above actually correlates with the last point as well, as software requires more and more features, quickly, you need assurances on your hand, about the correctness of your features in your code. Some developers actually pairing up to write tests and code at the same time. Extreme programming. Whatever your software development methodology is, please write good tests and easy to read/understand/change code. The business will thank you.
As a slight diversion from main topic: lately I’ve been casually helping an acquaintance getting their small project off the ground (in some of my free time). I invested in property tests very early (the project requires parsing of some pretty specific data). They were highly impressed by how the very first iteration of the code was not making a single mistake when parsing and importing into the DB, and now I have a money offer that I have to refuse because I’m not gonna work extra behind the back of my very awesome employer.
Oh well. But regardless: property tests, if you code your contract / expectations well, will catch your smallest mistake immediately.
This is a classic book on SE and very easy reading as well.
Introduction to the Personal Software Process - W. Humphrey (wiki, book)
Using a series of exercises the PSP teaches you to improve your estimating and planning skills, manage quality and reduce the number of defects in your work. I did the exercises in the older version of this book twice, once a week over 8-10 weeks. Perhaps the hardest book to read in this list.
The Open Toolbox of Techniques - Brian Henderson-Sellers et al. (book)
One of the harder books to find (in a public/university library), this book is a survey of various SE techniques, giving a brief description of each, when it is appropriate to use a specific techniques, its relative difficulty and further references. This book exposes you to a grab-bag of techniques that you can draw on when needs arises.
Given that most projects are group efforts this book covers the social aspect of software development. Like Mystical Man Month this book is very easy going and informative.
The Mythical Man-Month: “adding manpower to a late software project makes it later”
The Tao of Programming:
A manager went to the Master Programmer and showed him the requirements document for a new application. The manager asked the Master: “How long will it take to design this system if I assign five programmers to it?”
“It will take one year,” said the Master promptly.
“But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?”
The Master Programmer frowned. “In that case, it will take two years.”
“And what if I assign a hundred programmers to it?”
The Master Programmer shrugged. “Then the design will never be completed,” he said.
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.
Thank you very much for your time and willing to help.
As a new developer, I am working on a project that pretty much behaves as you comment and sometimes it takes to much time trying to figure out the best way to model your domain to avoid mayor pitfalls in the short term or simply trying to understand how a library works to use it in you current situation.
When you have the opportunity to talk to someone with experience, 10 - 15 minutes can make a big difference.
So thanks again and I will connect to the Elixir Slack channel for further live assistant or send you a direct message to have a Skype call.
Some of us can talk about this for weeks. But IMO wisdom cannot be transferred to anyone with words alone; one has to have grown to understand the problem the wisdom solves in order to accept it. Not sure that any amount of explaining will help.
