I've started a heap of draft posts here. Some are just just post titles, others are starting to get fleshed out. Before I go and delete them to clean up my dashboard, I thought I would list them out here with mini descriptions for what it was supposed to be about.
A timeline starting when I started to get into technology and acquired my first PC (from dumpster diving). It would talk about the communities I participated in, the jobs I have had and the different skills I have developed. I think I will keep this in my dashboard and work on fleshing it out more.
A listicle on everything to do with passwords that people (developers and users) do wrong. Number 5 will shock you!
Basically a long form version of this tweet thread.
I dislike the phrase "my door is always open". It puts it onto another person to provide feedback, when you really should be going out and seeking feedback. For other people to really feel safe providing feedback, they need to see that feedback is listened to and something happens as a result of it. Basically, if you aren't getting feedback on something, go looking for it!
This is another post i want to work more on and finish, especially after how one of my friends put it the other week. Claiming that the reason you don't have diversity in your team or organisation because there aren't enough people interested is a hand-wavy way of saying it's not your problem. What about the people you already have, how do they feel, are you providing them the opportunities to learn and grow?
This is another post I will keep around to flesh out.
At the end of last year my graphics card died. No big deal, I just took it back to the shop I bought it from to get them to fix it under warranty. What followed was 3 months of me chasing them up to find out what was happening with it. If all they had said was "we expect an update in 4 weeks", I would have been a lot happier with the service.
I think I could confidently say I have had the responsibilities of over 15 distinct job titles during my 10 years working in tech. All at only 5 companies. It doesn't map nicely onto a 2 page resume. I have to be selective about what skills I do and don't include. LinkedIn helps a little, but there really needs to be a better way to convey this information.
I've worked for several people who don't trust anyone who works for them. At some point in time they need to trust the people they hire otherwise no work will get done.
A question I like to ask in interviews. Do the people hiring really know the people in their team and what they do out of the office? I don't need to hear something deep, just some hobbies or holidays that their teammates have had. It helps convince me that you can bring your full self to work.
A discussion about different threat actors.
I've seen some really complicated libraries that were supposed to make development easier for other teams. Instead of that you could define simple guardrails and guidelines and let the teams work within them, trusting that they will do the right thing.
My experiences in gaming communities, student clubs and running events. The importance of getting the right people involved at the start so you grow organically with the right values. The importance of clearing the path and letting doers do and training them to lead, instead of forcing them to.
Things I have built myself. I really want to write this, but all the files I want for screenshots and to jog my memory are stored on my brothers machine on the other side of the country and he hasn't sent them to me yet.
Listicle of things that everyone is able to do to improve the security of the systems they are building.
Making it hard for people to fail. Alternatively, making them fail into the correct place.
This is something I've been working on for over a year. It's a piece about reducing the amount of work you have to do through automation, simplification and just stopping doing it.
Engineering standards and how they relate to MVP's.
Chief Problem Solver Mitch@MrTurnerj I really dislike the term MVP. Once you've decided to build it, it becomes a Product. What you ship is the Minimum Feature Set.
And seeing as it is going to production, it should meet your Engineering Standards. Simplicity should be a part of these.
#DevDiscuss02:41 AM - 06 Nov 2019
I remember reading a blog post about a timetable app and how they asked users what features they wanted. With over 50 new feature requests, adding all of them would remove the one biggest feature of the app; It's simplicity.
I've seen teams that treat these two topics as one. There are clear boundaries between the two but if you're not careful you can accidentally merge them into one, which makes it harder to do some things.
I've volunteered at a lot of events this year and wanted to write up what it cost me to volunteer, because it definitely was not free. I need to start tracking my volunteering expenses better, but this year it has cost me at least 3 tanks of fuel and a day of parking in the city.