Its the last day of our #NewJobJune feature week and we managed to grab a seat with Dave Rook, one of our Technical Leads here in Product Development. Dave has had quite the career journey before joining Redgate as a Software Engineer before successfully applying for and becoming a Technical Lead. Hear his story below…
Becoming an engineer
Like so many career paths, software engineering isn’t one you need to have had any formal training in, simply because you can work on it in your own time. I do feel some jobs require this, I just don’t think I’d trust a doctor to operate on me if they’d read about it in a few manuals and practiced on home with stuffed toys…
Many developers I know started programming as a hobby. It didn’t for me!
I got into computers due to a comedy sketch about hacking a computer… You’ve probably seen similar sketches in films, where some one needs to hack a password on a computer. They know they only have 1 option to get the password right, there are a potential billion combinations, they wipe the sweat from their head, enter some characters, hit return, wait a second, and then hear a bing sound as it’s right! This always intrigued me.
I started programming in 1999 and by programming, I mean writing HTML (which is mark-up language, it’s not really programming). I used Notepad to write the HTML because I wanted to learn what the system required and to really understand what I was doing.
Due to learning difficulties, I failed my GCSEs and my A Levels. I started a course at college, got diagnosed with a type of dyslexia, got special glasses and got A’s and B’s. I went to university, fell ill with chronic fatigue syndrome and was out of action for 4 or 5 years! I didn’t feel I could study, I needed a job so I started to work for free to build up a portfolio. I wouldn’t have a qualification to give, but I could offer work experience with real life examples.
Thankfully, there were enough webpages on the websites that meant I could essentially copy and paste existing web pages to muddle my way through to ensure we could keep improving the website and add new products, pages etc.
At this company, I also helped looked after the IT department and as one of my work experience roles was in Photoshop, I also did the graphic design role. Between programming, design, support and infrastructure type work, I often had to solve puzzles and this is where I realized I wasn’t dreadful and was able to solve every problem we faced (I clearly didn’t have any confidence at this point in my career, just lots of responsibility). I’m not saying I solved any particularly well or elegantly, but we went from blocker to progressing past the issue. For coding issues, it was down to me, trawling the web for what things I could find. Ultimately, I didn’t really understand what I was doing, and so couldn’t ask the correct questions to get the answers I needed.
Then in around 2006 I started to look into writing desktop software to solve a problem we had. The company agreed to buy Visual Studio 2005 and I started scripting in .NET. And I mean that literally. I didn’t understand what a class or a method was, let alone any OOP concepts and so I tried to program in a script like manner. I didn’t get far in this world, and so decided to park the software project and attempt ASP.NET as I understood the web world better.
Since I didn’t know the basics, nor the structure of a WebForm file it means it was a frustrating period of time as I put everything into a single method that ran in the code behind. Every page on my new shiny website implemented near identical logic to query a database for the data to show.
At this point though, my department was achieving more than we ever had before. I was running the IT department with 1 graphic designer, 1 Auto-CAD designer and an IT support engineer. We had 5 websites over 3 frameworks (with nothing shared between anything) — 2 x asp (classic), 2 x ASP.NET (WebForms) and 1 MVC.NET.
The code was still dreadful, technical debt had built up (with hindsight, it was already in debt before I started) and I was able to strike a deal with the company and get some training. The trainer introduced me to basic OOP through to N Tier applications. And I was able to start refactoring and improving. It was at this time I passed the MCP exam for .NET 2.0 Eventually we had 6 or 7 websites (in multiple languages), multiple desktop applications and I’d help expand the company’s IT infrastructure with co-location services to help our new offices in Hong Kong, USA and Germany.
It was a difficult yet rewarding time. I’m sure you know the expression 2 steps forward, 1 step back, this was more a stumble forward and 2 steps back… Not only was I juggling too many things, I was the only developer with no real support (despite now realizing being thrown in the deep end has its merits).
Since I wasn’t being exposed to best practices, I didn’t even know of coding standards, nor was I learning from others, I realized it was time to move on. Since my last role was mostly web based, I’d applied to a desktop application role to further my knowledge of WPF. My next role was on a distributed system, where we had 7 servers running to support the functionality the we software maintained. Essentially, the application downloaded material from various publishers around the world, parsed it, created abstract texts and summaries and published it on the website. The files we downloaded were not always text, some would be scanned image documents and so would have to go through an OCR process. Other parts of the system would provide functionality so experts could read the text produced from the OCR process and correct where required.
Moving from a tight nit world of separate monolithic style applications (although by size, each website had a very small code base) to a distributed system was tough and there was no training. I had to try to work It out for myself. I was in a team of 4 and was in a pure dev role. We didn’t talk. During my time here, my first daughter was born. I was out of the office for 2 weeks (as the company offered a great paternity package). When I got back, 1 person said hi as they walked past me and no one else said anything. We were totally siloed despite sitting beside each other and working on different parts of the same project. They had told me in the interview process they were agile and they had ceremonies (what-ever that meant). The truth was there was no real structure — we worked on the thing that they were asked to work on by the business unit and wouldn’t change until the work was done. Priorities didn’t change! The application we maintained was built and worked and there wasn’t a great deal of work to do. In fact, my boss spent around 40% of his time, every day, playing angry birds on his phone! I even asked “did you employ me by mistake” which is a phrase I didn’t think I’d ever say.
One of the devs in the team came from a contracting role. The company he came from were the same contractors who actually initially developed the system we were maintaining, and they were told to make the code horrible in order to keep the contract going! So, I was unable to get the mentoring I had craved, but I’d now been introduced to testing, distributed systems, a little more WPF, Windows Services and message queues. Since this application was a desktop application, I continued to work in my spare time building websites, ensuring I didn’t lose any skill in order to keep my options open. I applied for my next job. I remember the interview well since the interviewer asked me a long list of what things I knew…
Interviewer: “Do you have any understanding of how mobile coms work?”
Interviewer: “Do you know this certain namespace”
Interviewer: “Do you have experience in multi-threaded applications”
I probably answered no to 70% of the questions they asked and so was a little puzzled when they said I seemed like a good fit and offered the job. I got the job because of determination, the fact I was after a challenge and because I’d worked evenings and weekends keeping my web skills as fresh as I could. The company’s working methodology was rapid. Rapid development, fix as you go, forget it when you could. Over 9GB of code (minimal resource files), no best practice, no agile methodologies, no unit tests (yes, you’ve read that right).
Around this time the company had a major falling out with a major customer and the customer demanded we adopted agile methodologies. And we did. We moved to SAFe (you could argue it’s not agile) and it was a breath of fresh air. We even took the tests and became practitioners and I completed the PM/PO course. We had TDD training and unit tests become compulsory. We didn’t do agile in a good way, TDD was not mandatory but that didn’t matter. It was a step in the right direction. We were doing something similar to scrum. We had a scrum master. We had stand ups (well, sit downs). We had retrospectives. At least, I could now code and learn and master these practices… Of course, things don’t work out that way. I had finished the project I was initially employed to do and as such, no longer needed to lead my team of 2! I must have demonstrated some ability because I was asked to take on the architectural project although I honestly believe it was also because I was the person available.
As already mentioned, our application was a monolith and it was failing us. It was technical debt personified. We knew what we wanted to do, we wanted to have our hardware produce data, our software parse the data and other software to report on it. This meant big data as the hardware could spit out up to 5gb/s. We had around $600k to spend on choosing the right architecture from the right vendor and the research was mostly down to me. So, the first thing we did was create a strawman. For the first time, I moved from “how” to “what”. Instead of worrying how it would do what it needed to do, I just focused on what it needed to do.
This took a while 6–9 months later, we had agreed with a vendor what we needed. In order to continue, I moved into some hybrid PO role. I got to code every now and then but mostly, working with the various teams in order to get data from one end of the pipe to the other. This meant understanding what our project needed (the best I could) and dealing with understanding (to a high level) what changes occurred in the hardware side, through to what the parsing software did and how the reporting teams handled it. In total, there were 6 teams and I worked with 4.
I’d learned some C++ (enough to know I didn’t like it), worked with gigantic code bases, got an understanding of source control, seen what agile could be, really understood technical debt, worked with teams instead of people and got a better understanding of the business side as PO. I was fed up with 50 + hour weeks, no pairing, managers who shouted and “punished” their staff, belittling was a managerial technique, rigid agile practices, no customer research, no lean approach… and so I felt it was time to change.
I then arrived at Redgate and happily joined the Clone team. The architecture was smaller than what I’m used to but everything was great — the methods are small, they have naming conventions, coding standards, agile working methodology, a lean approach, customer research, unit testing and a sensible work life balance. This is great! Finally, I got to code with some best practice! And it was then I realized, I’d spent so long not developing every day, that I no longer could develop every day. I missed the different challenges that leading teams brings (at a person level and at team to team level). Around the same time I had this realization, a tech lead position with Prompt opened and I applied for the role. Thankfully I got the position.
I’ve learned so much, its hard to offer advice in a simple to use way due to not having context but…
- It’s OK to make mistakes — Try to avoid them of course, don’t be flippant about it, but mistakes do happen. Instead of being negative, use it for what it is; a learning opportunity.
2. Test and test and test Don’t test everything though! Test what you need to test and understand why it needs to be tested. This is why test completeness is more important than test coverage.
3. Only spend the right amount of time doing anything! If you were training to jog up the stairs, you’d probably take a lot less time getting yourself ready compared to running a race. Same as software. People can spend too long getting worried about syntax like a nested if statement or if they should have used this pattern over another… Conversely, don’t just hack it together so it works, do read the companies coding convention documents as this will help.
4. Ask questions. This is super important! If you’re unsure, ask questions and if you’re not supported with answers, get a new job! It’s OK to ask questions for clarity and questions to challenge concepts and ideas.
5. Engineering is not coding. I wonder if this will cause debate, but engineering is about solving problems, not about coding. Software is often just one way we can solve the problem, and coding is just a way to get it done. Understanding what the problem is, is probably one of the most important things about being an engineer.
6. It’s not about communication. Again, a little dangerous especially as I’ll come clean and say it is about communication but only as a side effect of collaboration. Working by myself for most of my career has really proven that I get better results and achieve greater things when I work with others.
7. It’s not only about programming. Cultural fit, helping others, making things better (continuous improvement) are very important. The majority of senior engineers I speak to usually do not put coding ability as the most important skill they think people need to have — it’s always high on the list, but probably not as high as you may think! So don’t be an intolerable genius as it won’t help you in the long run — focus on your soft skills as well.
8. Look for the benefits. For me, Redgate is easily the most enjoyable place I’ve worked but I still enjoyed my other roles. They all brought opportunity, be it good and bad. Understanding how not to do something is often as valuable as knowing how to do something. As such, always look for the benefits and opportunities as they’re likely to be someone everywhere.
9. Lead. It doesn’t matter what it is (coding, process etc). You’re part of it. You’re contributing to it. Don’t just contribute, improve it! Tiny improvements are great, you don’t need to rewrite the process! And by doing this, help and encourage others to do the same. And do this with everyone on your team, including the manager(s), designer(s) and developers.