Weeknotes - 06 Makers

🌈 The Sixth Week

Week 6 was our first group project; our first opportunity to organise our stand-ups and retros, plan a project from a 'client' spec, and implement it however we wanted. It's been a liberating task!

Team Work

We worked in teams of four. My teams' approach was to have daily stand-up and retro meetings, gathering at points throughout the day to give and get feedback on our status. We started by writing user stories for a Minimum Viable Product (MVP) and deciding what technology to use.

We chose to use JS for the learning opportunity, but decided mid-week to pivot and switch to a more familiar Ruby tech stack. As a result we were able to build a working web-app much faster, but due to lost time our approach was rushed and the final product was much simpler than hoped. Laughter is a meter of success at Makers, we joked about seagulls a lot and got through disappointment together.

💡 Pivoting is normal! It's often done where there are gains in cost, maintenance, or speed to be made.

How do you decide to fail fast?

• clarify the approach early and often - is there useful info missing or unknowns that will affect your progress?
• collect as much data as possible, as quickly as possible, and decide what 'good' looks like - don't think about perfect.
• Make a team decision, and come to it ASAP!

XP Values

XP means extreme programming. With it comes a set of values aimed at helping dev teams produce an improved quality work in a better environment (compared to non-agile, not-XP programming teams). If you haven't heard of XP before, you may be disappointed to learn it's not related to thrill-seeking.

Simplicity. Do the minimum! Get to your MVP quickly.

Communication. Meet daily face-to-face, work as a team on everything, and make decisions together.

Feedback. Demo early & often. Listen to suggestions and make changes. Adapt your process, not the project. Deliver working software.

Respect. Everyone has value! Respect the customers expertise and, be good to each other.

Courage. Give truthful progress reports and estimates. Plan to succeed, and adapt to change without fear.

💡 Identifying the MVP can be tricky. Look for those items in the specification that have the highest impact and those which are urgent - these should be prioritised first. Make something that works and can be used and understood by the clients.

She Made It

Makers held the first She Made It event, where attendees heard from three women on the topic of changing career.

Here are some of my takeaways...

Jessica Sapick:

• coaches help you develop self-awareness/coaching lets you hear other voices.
• Unusual career paths have unseen benefits (such as knowing how to be in uncomfortable environments - and to avoid working in them).

Charlotte Zhao:

• Learn from other's experience by speaking to them, asking deeper questions can build stronger friendships.
• Have conviction in interviews; clear doubt before stepping into the interview room.

 "Allow serendipity to take place" - Charlotte Zhao

Becks Hookham:

• It's OK to outgrow something that was once interesting!
• Weak connections in your network will provide work opportunities - friends of friends, and acquaintances.

Misc.

☕ Shout out to Hanna who asked me to be her mentor at Makers

💒 Took some time away from code this weekend to attend a joyous wedding and recoup

🍪 Proof-read a new chapter of Learn Go With Tests for quii and he accepted my PR

👀 Passed an eye-test, feel irrationally smug about it

Comments

[David Wickes]

I'd love to hear more about the pivot and your retrospective(s). What did you learn about choosing technology stacks?

[ruthmoog]

I wrote a reply, didn't send it, lost it... here's another go:

on choosing tech stacks:

Choose whatever you want and explore something new! The difficulty we had with this 1) time restriction, 2) not being able to identify what we needed to move forward, and 3) being misguided by our working knowledge.
I'm going to assume that whenever there is exploration and new tools involved, the last two problems will still happen. And does anyone work somewhere with endless time to indulge their curiosity?

• For working to a deadline, time-boxing exploration is a good idea, or, if it's a tight deadline, choosing a stack you're familiar with, and switching out a tool with something new if it's more appropriate with more confidence of how everything works together. Identifying what you dont know is hard! Practise and experience with more & varied technologies would be helpful.
• The assumption that you know what you're doing is probably a mistake kinda often? In our case it was having too strict an idea about the MVC design, and attempting to have the MVC design model guide the system we were building rather than the system we needed shaping our MVC model. Being able to decide the smallest thing you need to build first/next - and why - with a team gives some focus. Pretty sure having a variety of experience levels in the team might make life easier, but I wouldn't assume experienced devs don't make bad assumptions sometimes.

on retrospectives & pivoting:

we followed a typical white board reflection, and thought about our goals,

• are we having fun
• are we better devs than yesterday
• are we getting closer to our MVP We realised early that we weren't writing code or working together while researching, and team members were not having a similar journey. Since we needed more research to move forward, we time-boxed investigating and decided to review when the time was up and pivot if we didn't know what to do by then. We deffo could have pivoted earlier! As a rule of thumb, figuring just enough info to do the next thing is a fair tactic.

What do you think? Any tips on choosing a tech stack? Do you typically get to be part of that decision in your experience, and, as a junior developer? Our decision in the remit of the course was very much 'Ruby or JavaScript' than 'what are the best technologies for the job?'.