 Alright, so good evening everybody, thanks for coming, for those of you who do not know who I am, my name is Elwin and for Living I Code for the Singapore Government. Over the next 10 to 15 minutes or so, I'm going to talk a little bit about my career as a developer, including the time when people realised I was a little bit more senior than the others and decided that I should be doing a little bit more non-coding responsibilities. And I'll also talk about why I still want to keep coding even though I've got these newfound responsibilities and hopefully that might explain why I decided to scratch out the first part of my title. So, a bit of background of myself, I have been coding for about the better part of a decade and a bit now. Most of my time has been spent working for the investment banks, working on large scale trading systems and that sort of thing. In more recent times, I transitioned to the public service, I now work for GovTech Singapore and that was the point where I basically started assuming more non-coding responsibilities. We'll get to that in a bit, but first maybe I'll take you back to the time when I first started out. So, I joined the large US Investment Bank around 2008 deep in the middle of the subprime financial crisis. It was a time where there was a lot of change going on due to markets evolving in response to the crisis as well as regulatory demands being put out by various financial authorities. And it was quite tense for everybody involved but it was also a great learning opportunity because there was a lot more things to build now and I took advantage of that. So, I built a lot of things actually from simple crud apps that stored meter data about the systems that we had in the bank to business rules engines that kind of consumed large amounts of market data. And later on I started playing around with Hazelcast which is a clustered in-memory database which was used as a key value pair store. So, that was great and on top of that the bank I was working for was a company that saw technology that could either create new capabilities for them to serve their clients or to enhance their pre-existing capabilities. And as a result of that they invested a lot of money and time into actually building out our tech infrastructure. So, everything was well organized and on top of that there was an environment to learn. Not only was there formalized training courses, there was also informal meetups for the developers to come together to discuss and exchange ideas. So, all that was great. I felt I was learning a lot, building a lot, practicing coding and basically growing as a professional. So, that was all great except for one particular thing. There were a lot of senior managers that I saw around me who were very dull, very miserable, very sad. A lot of them used to be competent coders in their own right when they first started out but then over time the only development environment they were familiar with was Microsoft Outlook. So, if they were not sending emails, they were going to meetings. If they're not going to meetings, they will answer emails in relation to arranging meetings. And the only time you actually saw their faces light up was when you go up to them and say, yeah, there's this system you wrote 20 years ago that nobody knows how to fix and it's broken in production and only you know how to fix it. At which point they was like, oh, cool. I can actually fix that thing. I'll fix it. Just stay there. Let me write, let me implement the patch. Let me write the patch. I'll give it to you and go patch production and then we will all be on our merry way. And once that's all done, then they return to their old gray miserable cells and return to Microsoft Outlook. No hate on Microsoft Outlook, I guess. So, it kind of concerned me enough as a developer to actually ask around about what my career progression is going to be. And I think this might be a sentiment that might be shared amongst the more senior developers amongst us. As we progress over time, it's inevitable that you might actually have to take on more administrative roles, more mentoring roles, and that would cut into your coding time. There were, in that particular institution, there were some exceptions. There were some senior people who had been with the firm 20 years and were still working on technical stuff, but they were more the exception than the norm. The catchphrase management is inevitable was told to me. So, it did concern me a little bit, but I was young, I was fairly indestructible, and I just continued my merry way over the years. I kept working for the banks until I decided to join GovTech. Now, one of the first few things that I was told when I started working for the government was that I was going to stop working in Java to start working in a completely new language, JavaScript. Now, the names might be similar, but they couldn't be more different from each other. Java is this very verbose language which dealt a lot with types, with a very long bootstrap time, which gave you a lot of control over very low level things like spreading and concurrency, JavaScript, completely different things altogether, very concise as a language relative to Java anyway, and very limited in terms of how you can control the low level stuff. So, it kind of concerned me a bit at first because I kind of built up quite a fair amount of experience working with Java and now I'm kind of being asked to throw all this away and use a new language. And given the fact that Java is still quite prevalent in industry, there's always the worry that you throw all that away, start working on something, and then you wish to return to work on Java only to find that your skills will no longer as relevant as it used to be. And there's also the risk that I might not be able to keep up learning JavaScript compared to everybody else because you get older, your learning capabilities may not be so nimble in terms of learning new things. But, you know, maybe that language change wasn't a bad thing. It's not like I'll be throwing away all my lessons. There were some things I learned in Java which would still be applicable to JavaScript, like things like being mindful of how you design your programs, for instance, or how you go about debugging an application. And some of the things that I've kind of learned in Java may not be so relevant today. Like, I can't remember the last time I actually had to worry about multithreading and concurrency. So, you know, overall, it was still an opportunity to learn, right? And this was my in-road for me to go take part in growing and vibrant ecosystems. So, you know, without much further delay, I decided, fine, I'll just keep contributing as a senior software engineer within GovTech, still coding, still learning new things and making significant contributions. And then I was told, you are going to cut back on your coding activity and actually start doing more mentoring instead. And at that point, I was like, oh, okay, well, that's cool. At the back, I was really worried because I did enjoy coding a lot as my day job and, you know, now with the responsibilities to mentor people that's going to cut into my coding time. And, you know, part of me didn't want to lose the ability to code or even coding as an activity. And because if that happens, then I wouldn't be able to enjoy what I do. If I get out of touch with coding, it may not be effective even as a mentor to the other junior developers or even be capable as a senior staff within a technology organization. I mean, come on, right? You know, senior staff, you're a technology organization and you're creating technical. I mean, something is quite wrong there. And at the back of my mind, I didn't want to end up like those miserable senior managers I saw early on in my career. So I kind of realized that I had to keep coding somehow, right? I have to am all over justify to my superiors that whatever I am doing in relation to my coding activity is not going to impinge on my other responsibilities. So with that in mind, my coding activity will have to be somehow short and diversity, which would probably make it good for just very small pieces of functionality within and self-contained projects. Or in other words, I'm going to have to become a junior developer again, right? So there were two broad avenues through which I was able to do this to help me keep coding. So the open source ecosystem turned out to be a surprisingly fertile ground for me to keep practicing that sort of thing. And I mean, suffice to say, GitHub has managed to facilitate collaboration between developers at a level that we have never been able to see before. Typically, your work interaction with the open source ecosystem is your work system has a dependency on an open source library. It's broken or it's missing a feature. You get frustrated because the maintainers are somehow missing or don't have the time to actually work on it. So I decided to make a pull request yourself. I kind of went one step above beyond that. So even after I submitted the fix or the feature request that I wanted, I lingered around. I continued to maintain the code somehow. And the open source library maintainers, they tend to be quite appreciative of that because they themselves tend to be a bit busy. They have their own life to live. And if there are more people who are around to actually contribute to the development of the library, that's great. That means everybody wins as a result. So for my part, it kind of allowed me to keep practicing in the form of reading a code base which I've never encountered before to try to understand it in context and to interact with other developers who are not my colleagues. So in other words, they start to interact with them as a peer or even as a subordinate depending on what the hierarchy is like. So it's kind of like working on a small part of a larger code base with its own upstream and downstream dependencies. Of course, there's one drawback. It's going to be very hard to justify trying to do this during work hours, especially after your own work needs are done. So you will end up having to spend a lot of time outside of work trying to do these things. And I think for many of us, we do have lives outside of coding. So it's a bit of an ask to try to contribute to open source. But still, I think there are benefits to be had. This is a conversation I had with the author of the NPM package XML Crypto. As the name suggests, it provides cryptographic signatures for XML documents. Nobody was actually actively maintaining this library because nobody really does XML with Node.js. Everybody uses JSON, right? But Formsg, which is the government form builder, we kind of need to use this because we interacted quite extensively with sync paths and quad paths. And they are basically a SOAP-based service which XML messages being passed back and forth. So it's quite satisfying that the changes I've been putting in actually benefited people around me and that people actually are appreciative of what you do to the library. So that's open source. I'm going to talk about another approach, spin-offs. That kind of involves either partitioning a part of the code base into its own standalone project or standalone system or standalone library or whatnot. Or you create something that kind of complements the code base that you're kind of working on. That's kind of more easily justifiable than spending time on open source contributions for a couple of reasons. So one of them is that if you're shouting out code from the main code base, the original code base is a lot more focused. So it's actually working on the things that you have... that it's actually trying to solve the problem that the main code base is trying to solve. If your superior is kind of asking you why are you spending all this time trying to code and like separate out code or building new things to complement the original code base, the usual compact I would usually use is... I'm not really coding. I'm actually trying to organize things to facilitate the work of my colleagues so that they can be more effective at their job and that usually sits well with them. And in the meantime, by doing all this, I'm actually killing two birds in one stone because I get to be a junior developer again, but this time on a smaller self-contained project. And I think one of the prime examples of this within our own... GavTech's Open Government Products Group where I work in is the small pass. So this was basically a build by myself so that I could help my colleagues working on FormSG to build their functionality around sync pass and code pass without actually having to connect to sync pass and code pass. And the reason why we had to do that was because setting up sync pass and code pass on your local Dev Machine is very tedious and also means that anything that you wanted to test on your Dev that top required connectivity with sync pass and code pass. And that's not something that we can always guarantee. So by providing mock pass, we can actually have a more consistent Dev testing experience. I can keep talking about it, but if you want to find out more, just use the QR code to go find an article or just go to blog.data.gov.sg and click on the latest article and you can read more about that. So that's kind of everything that I have to say about this topic. And I hope that I've been able to impress about you that as you get more senior as a software engineer, a technological change and management responsibilities, those are inevitable. That will be a part of your day-to-day work, but there will be ways around managing that as well as your own coding activity. And hopefully when you're asked to step up in terms of seniority, you will still have the means to keep coding both for your own benefit and that of your teams. Thanks for your time. I'll be around for questions.