Thank you everyone! - "Take your time."

I want to create a post saying thank you to all of the kind souls on fCC for saying that it’s okay to move slowly and to take your time with learning how to code. I am teaching myself how to code and have been doing so for about a month now. I am become pretty okay with HTML and CSS at this point and have started recreating published websites as a means of practicing how to use the code that I’ve learned. However, I have trouble concentrating for long periods of time and have to take a lot of breaks so it’s hard to feel like I am moving at an okay pace. It’s really great being able to read that are others are having to take their time as well.

Cheers to everyone and happy coding~


That’s right! It doesn’t matter if you complete it really fast because if you do it just to complete it and didn’t take the time to process what you’ve learned, you won’t retain the knowledge. Happy coding to you too!

1 Like

“Slow is fast. Fast is slow.” Good job on working through things. Happy coding!

1 Like

What a lovely, kind, and considerate thing to post. With a caring and positive attitude like that, I’d want you working on my team for sure.

I suffered with Imposter Syndrome for a long time because I thought I needed to go faster in my career experience. However, the most important thing is “to thine own self be true” or basically, knowing how long it takes you to develop a solution or fix, is the only thing that matters.

When you have your Sprint Planning meeting, you must be realistic with your estimates. Don’t give in to peer pressure with your estimate - especially if it is a ticket that you are most likely going to have to handle. If your estimates are done as a team average, then raising the time allocated to a User Story or Bug Fix will be crucial if you are to be recognised as a reliable, accurate and consistent employee. Just remember to communicate. Don’t be scared to object in the strongest terms possible about a bad estimate. Sure - it will cause the Burndown Chart to overshoot its estimated date of delivery of this Sprint’s MVP (Minimum Viable Product), but it is for the Project / Account Manager & Co. to understand what went wrong - as is typically the way in your clichéd imaginary design agency luxury office with high quality coffee and reasonable quality bread & butter (for toast plus in some mythical companies there are legendary tales of peanut butter and jam/jelly!) on tap. This is so you can act and imagine Living The Dream instead of your employer’s Managing Director who will be doing backstrokes through his vast hoards of gold and treasure that has been exchanged for his soul and the indentured servitude of you and all your colleagues. Having a SCRUM Master or Team Lead estimate the Burndown Velocity is where the User Story wasn’t atomic enough, identifying a lack of cohesion between portions of the User Story description by decoupling into two or more further Bug Fixes or User Story tickets.

The management should be held accountable for why the first stage didn’t identify the ambiguity of the Acceptance Criteria or whatever else caused both management and the developers from failing to correctly estimate the ticket length when you have finished and logged you duration. This is critical if the Duration was noticeably larger than the Original Estimate. We could note the Ticket Number or tag the ticket for review during the Sprint Retrospective. You would briefly raise the overrunning time taken, during Daily Stand-Up so that you have visibility to all key stakeholders, and they have the chance to maybe shelve the ticket and your work for a management analysis and review, as wel as you being allocated a different ticket (maybe sourced from the next Sprint since it is good to always have at least the next one or more Sprints planned.

Why not Google any of the above-mentioned terms if you are new to SCRUM / Agile Development? Every development team these days works utilising these design and analysis techniques. I highly recommend reading SCRUM: The Art of Doing Twice As Much in Half The Time by Jeff Sutherland, and Google for The AgIle Manifesto to learn more about.

Good luck!