Want to learn how to become a developer? There’s a lot they don’t teach you at university...
Neil Ashford is one of Tiny’s newer software engineers, who joined our team in mid-2020 as a graduate developer. We’ve asked him to share what he’s learned since he started working with Tiny.
How I became a software developer with Tiny
I studied software engineering at university, graduating in 2019. After big dreams of becoming a rocket scientist, and then an electrical engineer, I decided software engineering was both easier and more fun.
Back in 2016, while I was still studying, I started an internship with another tech company and continued working for them until mid 2020.
Then in early 2020, I applied for a graduate role with Tiny after I heard about a job opening from my friend (who knew our Senior Engineer and Team Lead, Millie). After a few remote interviews (because #COVID), I got the job!
Starting out with Tiny was a bit different because we were in the midst of the pandemic, and a lot of things were changing. There was no office to walk into on the first day. Instead, I got a call a few days before I was meant to start, so I’d know who to talk to on Monday morning. That person then set me up with all my accounts at once, from Slack and email to Github, Zoom, VPN access and more. It was a very detailed process, and Tiny had a lot of internal documentation about policies and procedures, as well as some online courses that covered their programming methodologies.
But the real learning started once I started the actual work...
How to be a developer: 3 things I’ve learned
1. Collaborating with a bigger team
As I started working on my first ticket for Tiny, I came across some technical debt, but I had an idea of how to fix it, so I opened up the file and got to work. After all, I do have that Boy Scouts mentality - it’s nice to leave the campsite cleaner than when you found it. If you spot a piece of rubbish, why not pick it up on your way to the bin?
But then I ran into something I didn’t know how to fix, so I asked one of my teammates for help. And they were like, “Neil, what are you doing in that file?”
It turns out, I was working inside the file that glues most of the editor together (AKA the scariest file in the codebase). It meant that if I’d made any changes, the QA team would have to start their work all over again - and it would majorly impact their workflow and other projects we had going on.
It was a bit of a wake up call, because previously, I’d worked on projects by myself or as part of a very small team. You’d change something, run two or three tests, check that it still works, and then submit it.
But TinyMCE has a lot of complexity to it. We have a whole team of people who need to run through every possible interaction and make sure that it still works before anything goes live, after all it is not just about simple interaction, it is about making sure all edge cases are covered. The more changes I make, the more things they have to check.
I learned that I couldn’t just get in there and fix things quickly on my own, but I was part of a bigger team and my actions could impact other people. Of course, I still believe in cleaning things up as I go. Especially when you’re in the file and doing things already, because you’ve already got the cost of QA going in to verify that everything still works. But, I won’t go hunting for little things to clean up. Especially not in the scariest file in the codebase!
About 6 months into working at Tiny, I did find a legitimate issue to fix in that file. Instead of jumping straight into the file, I worked very carefully to make sure I fixed the bug without changing anything else — plus with the added benefit of having one of the senior engineers doing code review helped to ensure everything was done to the Tiny standards.
2. It’s worth investing time and money to make the job easier
Before joining Tiny, I either worked on my own projects, or worked with a much smaller team. All the libraries I’d used were those I could find on NPM for free. For example, I used to steer designers on my team far away from using modals (pop ups) on websites because they were tough to implement and easy to implement wrong (causing problems for navigation and accessibility).
In comparison, Tiny has a lot of internal tech investment. We have our own libraries and our own testing facilities specifically built for working with an editor, which gives us better performance than off-the-shelf components.
Once I started working for Tiny, I had to learn how to adapt to a different mindset and the different resources that were available to me. For a start, I don’t have to avoid modal dialogs anymore - TinyMCE’s window manager handles them easily.
Another example of this is our test runner. Before I worked with Tiny, I’d run automated testing on projects and they’d come back with either a tick or a cross. Trying to do anything outside of this was tricky and complicated.
But the team at Tiny has created our own automated testing program that’s tailored to Tiny’s needs. Our test runner makes it much easier to put your hands into the automated test and manually interact with it while it’s running. For example, you can open the test in the browser and run it there. You can watch as the automations run and the computer clicks on all the buttons. You can pause the test and take a look at things to make sure they still work. You can slow things down and speed them up.
There are so many examples of little things like that which are so much easier with Tiny. The team has put the time in to solve hard problems - whether it means creating a new tool or investing in an existing one. I’ve found that it’s often worth investing that time and money into making the job easier, rather than going with conventional tools or off-the-shelf products.
3. A direct link to customers makes work more meaningful
One unexpected thing I learned is that it’s worth removing barriers between engineering and customers.
After I finished my training courses, I moved onto training tickets, then worked on my first bug with Tiny about three weeks into the job. I spent three days doing what I can now do in half an hour (which is fairly standard for a developer on a new codebase, I think!). I finished working on the bug and went to make the floor request. This means that I put all my code somewhere for other team members to look at it, and read through my description of what changes I made and why.
Once the fix was ready, I hit “go” and I saw a message pop up on the bottom of the screen. Suddenly, I could see that the Github Issue was reported by a real human being who, at that moment, was also getting an automated message, “Fix now being processed by Neil”.
That was really cool because previously, the work I’d done (in commercial, closed source projects) had all these layers and was really indirect and anonymous. You’d click on the Jira ticket and work on the fix for the bug. I still enjoyed working on the problem, but that direct human connection made it a lot more meaningful. I now had a direct link between the work I was doing and the people I was doing the work for and it has helped make the fixing of bugs a lot more close to home, I know I am helping someone and can even name them.
3 tips for the next generation of developer grads
So, how do you become a developer? What are some steps you can take now (while you’re still studying) to get ready for the professional world? Without these three things, I wouldn’t be where I am today:
- Intern - Interning is something I’d strongly recommend to any undergrad engineer. You’ll learn a lot more from work than you will from studying.
- Work on projects for yourself - I think working on projects for yourself can help you hold onto that creative freedom and the things that make developing fun. Plus, build more skills while you’re still studying.
- Start immersing yourself now - There’s no need to wait until you’re in the industry to start learning from the industry. Go on Hack, the r/programming subreddit, or stick around here on Tiny Blueprint. Read the posts and articles from people who are at the forefront and who are coming up with new things.
That’s it from me! Hope you’ve enjoyed these insights on how I became a developer and what I’ve learned from working with Tiny so far.
If you’ve got questions or your own insights on becoming a grad developer, head over and continue the conversation on Twitter @joinTiny.
