It's seemed easier to write these weekly reviews when there have been fewer happenings; the last few weeks have been more fast-paced. It's an interesting thought that having more things to write makes it more difficult.
To break the paralysis, I hope to pick out a few events.
Conferring
I'll write up something separately, but today was the annual Brighton Ruby conference. My company only had myself attend this year but we have had up to a dozen make the journey along the south coast.
While I caught up with a few ex-colleagues the vast majority of my time was spent on my own, so I think for future events my attendance will depend on being in a group.
Conclusion
I enjoy the talks at these events but I'm not a networker. There's something about being there, though. We encourage anyone in the company to go to events -- I'll shout about it more next time!
Diving into the Unknown
Back-story: someone wrote some code. In fact, they wrote lots of important code, and it was good. In the interest of knowledge sharing, an improvement was given to the team to pick up rather than the original implementer.
The change wasn't complex: ingest some data and update our copy, shuffling the format a little on the way.
Wonderfully, I didn't need to talk with them to change their code: I could rely on their tests to prove my "happy path" would work. Moreover, the code was layered in such a way that meant it was easy to change. This wasn't by accident. We knew that further ingestion of other parts of the available data was inevitable, so they kept that area simple and segmented.
Conclusion
Change is not easy, but we can make it easier. Of course, write useful tests; that helps everyone that sees your code. You can help further by restraining yourself from adding just in case features: instead leave it right before you add anything that's not necessary. You'll leave a clear place to start work next time, whether that's by you or your colleagues.
Top comments (0)