Here are a few tid-bits of wisdom I’ve learned thus far in my journey as a Ruby on Rails developer -- enjoy.
It’s a marathon, not a sprint.
Don’t get burnt out trying to prove to yourself or others how great of a programmer you are. You’re work will speak for itself. Play the long-game by working efficiently at work, and steadily learning new programming practices. Don’t kid yourself -- you don’t know everything and that is fine. One Step At A Time ðŸ‘
Product deadline estimation is not easy
Our first big project as a team seemed “simple”. We thought we knew how to do everything and we did not factor in time for running into roadblocks or any other issues that come up in software development processes. I’ve learned your initial estimation is probably short by a week or two, so it’s a good rule-of-thumb to add at 1–2 weeks onto your estimation.
You could work on the project for a few days and then come back with a revised deadline. It’s always best to estimate with more time, rather than less, because if you get the job done earlier than expected, you will get huge props.
Talk often to the stakeholder(s)/manager
Keeping your bosses happy is fundamental for project success. Keep them in the loop. Produce small things as you go to keep them satiated. Even if they don’t understand how software development works behind the scenes, just showing them simple front-end features goes a long ways, and they just want to see progress -- everyone is invested in it man!
Team Building pays off big dividends
I like to use the analogy of being on a sinking ship headed to shore. My team and I are all on the boat together. We can’t bicker and point fingers at each other -- this leads to us wasting valuable time that could be used to get us to shore. We have to plug the holes and work cohesively in order to reach our goals.
Many different parts must work with each other to come bring everything together in the end. When you are dealing with hundreds of thousands of lines of code and you are all working on very complex features, there has to be a “I got your back and you got mine” mentality.
Go out on a Thursday or Friday evening after work and get happy hour together or go to Top Golf -- or really anything but just make sure it is outside of the office. This helps bond co-workers, which is necessary for long-term team development/cohesiveness and ultimately shows you, "hey, my co-worker is just an average normal human too!"
Be friendly, be open, be encouraging to others.
Celebrating small victories in programming really does help. Celebrate your own victories, even if it is some tiny bug fix. Have a co-worker who made some sweet Regex method? Give them a high-five and tell them job well-done. The list of benefits are tremendous.
Don’t be a know-it-all.
Thinking you know it all leads to disaster. Understanding there is still so much room to learn and grow will set you apart from everyone else. Don’t become stagnate in your way of thinking or coding. You want to look back a month from now and see that code you wrote then and say, “Yuck”, because then you know you’re improving, that is extremely important if you're going to get better at developing software.
Top comments (5)
I bet our newest devs @andy and @codeswitch can relate to a lot of this.
We do some estimation, but rarely set deadlines for the exact reasons you outlined. @mscottford recently offered me and my team a good framework for doing estimations, which was to add a confidence level. "This will take 200 person hours and I'm 33% confident in that" for example.
For sure, I've done some internal estimation and time-boxing of certain tasks and it has helped me a lot. Also, as a new developer and member of the team, it helps me know when to ask for help if I really didn't meet my estimation or I run into a blocker that increases the estimation.
Oh, that percentage of the estimations is a game changer for me. Nice!
Although, in some businesses and some clients, they may not like that approach and I don't know how to dress that up for consumption when they're looking for deadlines no matter what (some have very good reasons!). I would likely look back to scope and what I'm able to do/what my responsibilities are. It's a tough one. Any takers on this question?
I've been taught recently to take it week by week, which has been really helpful and useful for the stress levels. You don't feel like there's a huge mountain in front of you that you have to climb. Some people use sprints for tickets and the like, but I look more at components or features that I can show.
I'm like a scrumban sort of thing? I very much like working at capacity doing more of a kanban style linked to features.
Also, I'm very late to the conversation on this one.
This is great advice Ben, I will definitely run @mscottford 's framework by my boss-- it makes a ton of sense! Thanks for reading!
Overall great advice! As @ben mentioned, I'm pretty new and green to the job, and I always have this sense of urgency to do more more more. That urgency also compiles with a need to do it quickly, too. I always need a reminder that it is in fact a marathon, so thanks for that!
Also, I'm glad you mentioned being friendly and encouraging. There's always a getting-used-to period that everyone has when there's a new person, and I've found it being really helpful to be the one to be open and positive. It's a great thing to take the lead with, and sometimes that little bit of social glue is all that's needed.