 Okay. Hi, I'm Gabe Hollamby. My title isn't Senior Developer anymore. It has been in the past. Now I work here at AWS as a technical evangelist. It's an interesting title. All it means is I'm a software developer who also likes talking with people, speaking at conferences, writing blog posts, organizing and attending meetups, all of that sort of stuff. It's a really awesome job. AWS built a lot of cool stuff. My job is to stay on top of all of it and educate developers about what they can build on AWS and inspire them to build cool new things. So if any of you have any questions about that, we can talk. But you know, tonight I'm not even here in a work capacity. I'm here in a personal capacity to answer any of your questions about my career as a senior developer or what it's been in the past. I've been writing code for over 15 years now. A lot of web stuff, but a lot of backend stuff too. I've done a lot in the educational technology space, real-time online tutoring. I worked at Pivotal Labs and Neo doing agile software development with Mike at the time. That was really great. So a lot of test-driven development, extreme programming, that sort of stuff, agile dev. And then before coming to AWS, I worked at a company called Spire, which was here in Singapore and built nanosatellites. So satellites are about this big. We would design and manufacture them in Glasgow, launch them on many rocket launches around the world and collect data from space, bring them down and do a lot of interesting data parsing as well. So happy to talk about anything from my past. And I guess there's interesting questions going on behind us. That's why I'm here for laughing. Enough about me. Hi, I'm Shilling. I'm CEO of UI Leashes. And basically we are a developer tool to automate user interface testing for web application. As for myself, I started coding when I was nine, mostly because I wanted to create a new pet application for my pet. And I wanted to figure out how to make my scroll bar sparkle like all the other ones. Afterwards, I went to junior college. I studied computer science. And I think it's a horribly stupid idea to teach junior developers C++ at the start. It's horrible. Pointless is stupid, my opinion. And anyway, afterwards I went to SMU, Singapore Management University to study information systems, learned how to configure SAP for a living, did not do that. I decided to become a web developer in a startup and that's my life until now being a CEO of DevTool. Hi, everyone, I'm Ginny. So I was just thinking about how to introduce myself and then it so happened that a few days ago I got a notification on LinkedIn. So I went into LinkedIn and looked at my profile again and I realized that if you read my job titles from my current job to my last few jobs in reverse, it looks like a career progression. You got longer? It got more powerful. So basically I've been doing development since a long time, since I was a kid. Pretty much a thing around the same age as you did when you started as well. And then when I was in school, I decided to intern and I was doing something that I'm quite embarrassed to admit these days, some basic, visual basic specifically, not .NET, it didn't exist yet. So the other languages that I did when I was interning as well don't really register in people's minds anymore like Perl. Yay! Eventually I got into doing Mac OS and then from Mac OS, iOS happened and then after that I started a company doing iOS consulting and I was doing that for a very long time. So I was so-called CEO of that company and then I was invited to join another startup. Then I became CTO and then that startup got boughtable by Carol Zell so I became engineering manager and then I left and joined SP Digital which I'm now entitled principles of engineering. What that actually means, I'm not so sure except that I write code and I manage engineers. Yeah, so that's me. Alright, so great round of introduction and I gave everyone a chance to upload many many questions and the first one, tabs versus spaces. What is your answer? Whatever the repo was using when I came to it. Just use ESLINE, you are magically in that everything. You still got to configure it though. You can use standard. Okay fine. Which is two spaces? Space. Obviously a space. Bye guys. Answer. And the next one, what advice can you give for someone who is self taught in coding and looking for developer job? Where do we start? I don't know. You want to start? Let's start with. Okay. Although I actually came from a CS background. I had a CS degree but I was also freelancing. Before freelancing was a sexy thing. And this was before I even went to college. So it was a bit hard for a 16-17 year old kid to basically convince people that they should pay me money to build websites for them. So I guess one thing I had going for me was at least there was a portfolio of things that I put up online that I could show people. That got me a foot in. So I'm not sure if this answers the question. Really got portfolio. So I think if you don't really have a lot of strong credentials or experience if you have something to show people and say hey you know I built this. I think it's a bit more relatable. Well these days when I became a CEO I finally started interviewing developers and trying to figure out like who do I want to hire. I got a lot of resumes. So I do see that there's a difference between people who came in from the university background and people who came in self-taught is that those profiles that really stand out is when they show me a project they have done in school. But you like that kind of opportunity if you are self-taught. So the best way to do this is to build a portfolio of projects that you can show and not something very simple and shallow but something complex enough that you can explain to me how a problem actually how do you solve one of the more complicated problems in the application. And also generally a more interesting project that is different from what you've done in school or what you've done at GA will also help. Yeah my answer is pretty much along the lines of what you've already heard. Personal projects or projects that were involved in your studies it doesn't matter show code that you wrote that you can have a discussion about. I think it also helps if you're willing to talk about the messy parts about it too. I think a lot of times when we interview we always want to put our best face forward and that's understandable. But a question I like to ask is what are you least comfortable talking about in this code base that you're showing me? What's not good about it? Let's not talk about just all the awesome things you did but what did you do that's not great or that you would change if you had time? Really interesting discussions come from that that'll give me an insight into the level of maturity that you might have as a developer or your comfort level to be able to criticize your own code which I think is a good quality to have. I realized when I was hiring people I also tried to find out what they do in their free time so I kind of asked what do you do in your free time what projects, what side project are you working on that also gives me an indication of how passionate they are about writing code and being in this industry. Can I just add on to that though as a recent father, I have a daughter who is 8 months old now I used to be in the camp very strongly you've got to have side projects outside of work that you can do because that is the indicator for passion. It is an indicator for passion for sure but I think there are plenty of people that have a lot of obligations outside of work and can't get time to do more code when they leave the office that's totally fine too so I don't think you have to have side projects but if you do, it helps. There's something like having portfolios and putting stuff on GitHub but what about for people who work on a lot of private projects as in client projects and whatnot so a lot of contributions are actually in private repos. I had a problem when I was changing jobs as well so basically I just thought of the most complicated part of the application that I did that was very deep and I just explained an abstract concept like I optimised the reports in the application and I did this and this and this and this and the problem was this and this so if you could explain how you solve a problem abstractly in a very deep way, it helps. I've also interviewed quite a number of candidates who don't actually have portfolios or anything public that they can show so what I usually do is when I have conversations with these candidates I try to ask them to tell me, explain to me I'll just whether or not I know how that system generally works, I'll just tell them explain like I don't know and then from there I'll just try to dig deeper and deeper and deeper and to see how well does somebody actually understand something if they can explain to me very coincidentally very comfortably, I think comfortable is the key word here then you know that this person has technical depth, has enough appreciation of the the systems and the things that he or she develops with or works with and sometimes you may not necessarily be the most knowledgeable developer in the room but if you show the ability to actually really try to understand the things that you're working with that's already to me a positive sign that's cool, alright so that's for the next question what do you wish you knew as an Adrenal Dev? Can start from me Honestly, I think I wish I wanted to know a lot of things everywhere, a little bit of everything but I think because I'm a web developer and one of the frequent things that keep recurring was that the whole company we did not have automated tests and we didn't know how to do it and we keep arguing about what tests to do so I kind of wish like why didn't anyone teach us in school like how do you write good quality code instead of just making applications Yeah Wedding test I think for me one of the turning points where I had some of my own self-reflection and thought I'm becoming not a junior developer anymore I'm noticing this change in myself was when I became more comfortable reading source code that other people wrote and not just at the application level I think a lot of times you and I might work on a repository together some project, we're building something and whatever the thing is we're building the odds are we're using some sort of open source code for something, some library, some framework maybe multiple packages, doesn't matter we're leaning on other code that other people wrote and that's where we have questions about it where we need to figure out how to do something and I used to just read the documentation and that's a really great first step but the best documentation sort of is the code because it's the only thing that won't lie to you once you get comfortable reading it and so one thing I wish I told myself to start doing sooner was don't be afraid to just go look at the source code for that plugin that you're using or that library, whatever it is and ask a question about how it's working or if you wonder what other arguments can I pass to this function or what is it giving back to me when I call it go look at the code, just give it a shot and you won't always understand everything you look at right away but I guarantee you if you don't start doing it you're not going to get any better at it so you should just start and you'll get better with time I learned a lot of stuff from opening the source codes of all the third party libraries that I put in and you see my projects to be honest I don't really know how to answer this question because I'm still asking this question myself these days today and I think the the thing to keep in mind is that even if you're a senior developer in terms of years of experience in terms of you know having a bit more in-depth knowledge in a particular area you will always find yourself in a situation where you're learning something new that somebody else knows better maybe even a junior developer but you just don't happen to know it yet and you try solving it on your own and then somebody comes to you and say like hey you know I don't do this and you're like I wish I knew this earlier I wish someone had told me this earlier so it never ends so I think you shouldn't feel too bad about feeling like you don't know or you wish you knew something sure so in line with that how about this question in your experience what are some glaring weaknesses that self-taught developers have what can they do about it well I worked with a pretty good self-taught developer when I was still working as an engineer and I won my older companies and the thing that I found out there was a glaring weakness is that is knowing database design there's a lot of things that they teach you in school that you don't really get to explore and learn in your own if you're learning on your own time so one of these things is it's quite easy to write as Cal Curries but how do you design a database that is in some situation where you need to have fast read performance or fast write performance and it's a whole theory on its own that I think is a really important thing to learn if you want to build any kind of application that's one of the areas of gaps that I found out database design? okay so I'm going to editorialize for a second I don't like the term self-taught developers I don't think many of us are self-taught I mean by the definition that I think we mostly say that I'm self-taught too my degree is in English and creative writing I've just always been interested in programming computers and pursued it a lot on my own but this is never on our own right we're community taught there's a bajillion blog posts and YouTube videos and meetups like this nobody's self-taught anymore so remember that too right if you're feeling like you're just learning on your own you never have to do that journey alone of course you all know that that's where you're here so maybe this is preaching to the choir but one area I guess would be testing how to think about testing how to not be dogmatic about it which is hard because when you're first learning something what you want is rules do you want somebody else to tell you what to do and how to think about an approach to programming and a problem but the answer to everything always is it depends and it's true for testing too so figuring out the nuances beyond what do we feel comfortable with testing in which ways, what can we get away with what's going to be the right payoff in terms of investing time and learning how to test this new thing what's likely to break what's not likely to break based on what code we're going to touch these kind of things I think would be valuable for junior devs to develop more of an opinion on and again that just comes from practice and from lots of struggle and figuring these things out by writing lots of terrible tests and lots of projects over and over and over again and you don't realize it's terrible when you're writing them you only realize later, you know sometimes years later where you're doing something else and you go oh yeah I just learned this, why was I testing this other thing that way before that's silly so it really just comes from time and practice I guess for me it will be in terms of the way you write your code and how your code will scale when it's run over say for example large data sets or run over a lot of iterations so sorry oh okay alright sorry so I guess probably one area where I find that sometimes self-taught developers I wouldn't really necessarily say have a glaring weakness but maybe maybe have a slightly less strong foundation in would actually be in terms of how you write your code to make sure that it can still perform well and not run too slow or run out of memory crash when it needs to run over a large data set or it needs to run over many iterations for example if somebody, an easy way to write a code and get it working on a small data set could be when you have nested loops try running over a few thousand rows of data rows in your database and it kind of just breaks down but you know there are actually tools out there and resources for you to actually learn up on all these things on how to make sure that your code can scale can I add one more read the damn error message actually, I think that we can ask the question in inverse as well like what should some people who go through formal education what should they unlearn actually I find that a lot of school taught developers, when they first copy they want to do things the perfect way it has to be perfectly optimised and fit everything perfectly and I thought god damn it you spent two weeks on these projects I wanted it out last way I could have gotten things out if you did things break down the problem with a smaller iteration and solely build it from a good solution a better solution then maybe someday the perfect solution eventually yeah there's huge value in code that runs today huge value in code that runs today versus tomorrow or next week even if it's not perfect optimisation good is good but premature optimisation is bad that's cool that's about the answer and the next question and the list is in relation to this about learning how do you balance learning a lot about everything or deep dive into a topic so how do you know you're learning something that will be useful to you and maximises your time spent it's been a mouthful here this is all balanced but how do you balance between what the newest coolest framework to jump into figuring out what to get good at okay so for me I feel that when you're working on something or a particular technology let's say for example you're a web developer you will almost never ever work with just that immediate language or framework that you're working with so say for example you're doing React with JS you learn React you learn JavaScript but you also probably will be working with other things like for example you need to learn CSS if you're working in a if you're doing TTT you will need to learn about testing so frameworks like jazz, mocha whatever else from the gajillion frameworks I noticed there was a question about that as well and then if you're working in a continuous environment integration environment CICT you need to learn things like the Jenkins or you know the Circle CI or Travis CI whatever you're using you need to learn that as well and then you'll be writing some scripts to automate some of your build process and then you need to learn that scripting language as well could be say Python Ruby batch scripting and then you need to deploy months and how do you deploy maybe you need to deploy with Docker and then you'll be learning Docker so there's actually a lot of auxiliary things that you will need to learn in order for you to actually get your work done so I think one way you can start is actually by picking up all of these auxiliary things and sometimes those things can actually lead to you learning other languages for example if you use this tool called danger which is very fun is Ruby and you pick up Ruby and then if you do enough Ruby and maybe one day you might end up just doing Ruby on Rails because they needed somebody who knows Ruby and you knew Ruby Honestly I think for me I'm just really curious about things especially they just pop up according to what's adjacent to what I'm currently working on so but for me I try to follow where my passion or current passion lies and as a point it was in data analytics so I studied a lot of D3 and a lot of various analytics techniques but now my focus is more on like hey how do I make really great awesome high performance UI right now so I think it's good but I think generally it's good to try to broaden your knowledge and be decent enough generally and then I think it's better to progress into specializing into one branch that you really like Yeah I'm going to agree, I think that I recommend being a bit of a generalist at first but when you said about like picking up something on the periphery decent to whatever you're working on I think that really resonates with me too because Jenny enumerated a lot of things that you need to know in order to get stuff done need is like a really squishy term here right because like I don't need CI to write some code and get it deployed I don't need Docker, I don't need to write tests these are all things that probably are going to play a role in your software development life but it doesn't need to be from day one or day 50 or day 500 but what I think you should do is start with one thing that's related to whatever it is you want to learn how to do and again that's because you're picking a project you're making a project that's somehow interesting to you and you're going to let that drive your decisions for what technologies are you going to use for that now there's going to be a lot of options I want to build whatever this thing I'm going to use this language of that language it doesn't matter pick one that you have friends that can support you in because that's the most important thing because you're going to get stuck at two in the morning and you're going to want to have friends that you can ask then or the next day and you know it's so much easier to ask a friend than to figure out how to write a well crafted question on stack overflow and hope that it's going to get answered so really you pick something that your friends know learn that and then pick something on the periphery related to that and learn that too I don't think you should be learning more than one thing at a time so because then you're just learning all the time and you're not getting anything done and you're probably just doing it kind of badly across like a really thin but very wide spread so don't do that either choose your learning budgets carefully and deliberately I want to agree on the part about getting somebody to work on code with you so like pair programming and finding somebody who already knows that piece of technology so finding somebody who knows Docker somebody who knows about test development in JavaScript so get them to just show you the ropes show you a few things I remember we were back in New York and we were like working on a Python project I had if it was a Django project I had no knowledge in Python so I just sat with one of my colleague James and he was like really really he's really good at this and he showed me like oh this is how you do a function this is how you do da da da da in no time almost a week later I was writing my own module in Python right just because we need to so yeah finding a good partner or friend or somebody we can pair with I think that's very helpful right so thanks for the help we have we're getting into the career and skilling up into the senior developer kind of questions so how different are the responsibility of a senior developer versus a junior one and what is the career trajectory like well I think the responsibilities of a senior developer involves more being able to clearly communicate ideas to your team members so that's one kind of thing and the thing about what I expect from a senior developer is to be able to balance the requirements as if not the individual requirements like your password must be right but more like the requirements of security how fast this project needs to be completed as well as usability so balancing all of these things is really really difficult and I think a senior developer should be able to figure out like what's the best compromise to get the project moving forward in a reasonable reasonable standard career trajectory is quite varied you could go into project management part you could specialize into one technical part you could just be a very generalist that does solutions architect and maybe CTO someday I would like to actually say that so a lot of people have this thinking that the typical trajectory is junior developer and then you become a senior developer and then you become a slightly more senior developer and then you become say an engineering manager or you go into management but that's not necessarily always true the thing about going into engineering management is kind of like a parallel track so at some point of seniority then you actually diverge into two branches so one part will actually go more into like you know people management and that's the engineering management track but you can still be a very very senior technical lead you know go into like principal software engineer roles architect roles and that's like really you know remaining very rooted in the technical track so it's not like you know if you don't become a manager that means your career has stagnated it's actually two parallel tracks all together I agree with everything that you've heard about career trajectory and the relationship between seniors and juniors something that we didn't say yet that I think is also important to John is like code review so if you have a team and there's a senior dev on the team and a junior dev the senior dev should be reviewing the code of the junior dev and suggesting ways to improve it that's an art in of itself right like there's there's huge books and blog posts and podcasts written about how to do code reviews well and not well and just because your senior doesn't mean you know how to do it well at all it's it has to be learned but I think a good senior dev is also capable of staying on top of the repository seeing all the changes that are happening and taking responsibility for the mentorship and growth of the rest of the team and themselves and I think one more thing about being a senior developer is that one of the values of the senior developer is actually not so much in the their technical knowledge because sometimes you can be a senior developer role in technologies that are completely new to you so you wouldn't really actually be a senior or the most knowledgeable person for that technology but your value is actually in the experience that you bring to the table basically your battle scars you know the knowledge that oh you know if you do this thing we'll need to handle cases such as X, Y and Z otherwise things will crash and burn and I think that's where the value of the senior developer really lies is basically experience and that is something that you currently gain by literally you know staying you know staying as a developer and growing as a developer and eventually with years of experience you'll get there So in line with the question about responsibilities I also want to bring this up what are the skills that are required to be a senior developer I already mentioned previously I want the critical skill for being a senior developer and being able to communicate so this is like in line with code reviews so you have to be able to clearly concise concisely explain what how the code can be better and not give like fluffy vague answers and just leave them alone to deal with it and yeah so that's really communication is really really important and being able to prioritize our tasks because you as a developer you just get all the a lot of huge tasks here and there and some of them are urgent sometimes you just get like hey I got an urgent bug request or hey these clients say they want this feature but then of course sometimes you need to balance out and figure out which one is higher priority which one you want to float up and down related to that is figuring out when to when to leave the crappy but working code alone because I think most code starts out crappy right and then we have to make a choice do we make this code better or do we move on to the next thing and you know and then sometimes you move down to three next things and then you know enough about how your system is evolving that necessitates going back and cleaning up a little bit of the crappiness and the things that came before but sometimes it's the right call is to say we need to get this thing done we all agree this is bad but it's working and if we all agree that we're unlikely to touch it right now and the requirements that we're going to put this code through are not going to change in the near future then the best use of our time is probably to leave that alone and work on the rest of the things that we need to get done and again that just these kinds of gut calls of it's instinct a lot of the time you can't justify it and then that's the hardest thing again as juniors right you all start out I want my checklist this will tell me the rules will tell me when I'm done with this I move on to the next thing and it's not like that a lot of it just comes from experience and you know you use the term battle scar Jimmy I often think about building software as kind of like navigating through the wilderness it's a similar metaphor right like you never have been in the desert before but if I know how to you know survive and navigate through the jungle and you draw me off in the desert a lot of those skills translate and so we're constant to be a software developers to constantly find yourself surrounded by the new if you're not working on something new it's probably worthless because somebody already did it why are you doing it so that's we are always at the frontier of our own abilities and of you know that whatever we're developing and you just have to pick up the skills for navigating at the frontier and surviving and not getting lost for me I would say empathy actually so the ability to actually empathize with a variety of things from if you're building a product you need to basically be able to empathize with the user you know that you're building that product for that you're building that feature for someone doing a code review you need to be able to empathize with the other person and the constraints that they may be writing that code under it could be that you know that imperfect code that they just submitted in the full request could be because they need to get something done quickly and they had a tight deadline you know and this was the best that they could do in the deadline and it works it could be that they had technical constraints that they couldn't use certain technologies therefore certain options were not available to them and therefore they had to go with the second best option and I think sometimes as single developers sometimes it would be too quick to judge when we see things that are not perfect but I agree with Gabe actually that good enough is actually better than perfect sometimes if perfect is not working or not going to be delivered soon but good enough is then good enough is essentially good enough yeah I have this recent experience with writing how many of you guys use code climate? Code climate anyway it's a code scanning too basically it tells you how good your code is how bad your code is based on you know some standards out there so there's a ruby the part that scans your ruby code will tell me this part has too many lines this function has too many lines I was like I'm still capturing come on so yes learning how to let it go when Mark as won't fix for now I actually had a recent experience so I was working with a junior developer on some linting warnings and the junior developer was telling me that oh you know I don't want to do listening because there's so many warnings and I don't have time to fix them now and I was like that's fine you don't have to fix them all at once you don't have to clear to keep you know making sure that every build is completely clean especially if you have a deadline to work towards to finish your feature leave that warnings in make a note of it prioritized vision should be fixed first or vision you don't want to fix you just look at it because if you don't do it then you'll never know if there's improvement in your code base whereas these linting tools already tell you where it was to improve and that actually is a very good learning tool as well can I add on to that before you want extending the wilderness exploration metaphor a bit more we have this thing sometimes we call it the campsite rule leave the code base cleaner than you found it and to your point about linting you don't have to fix all of them fix one fix two done right spend five minutes making it better than it was when you found it I think that's a characteristic that's very clear this is a rule that you can live by I've been giving a lot of squishy advice but I feel like there are some things I can say that are just definitely good advice that you can follow every day this is one of them if you feel like you're leaving the code cleaner than you found it that's one step closer to being a more senior developer so in line with the question about senior developers maybe I'd like to answer this roughly slightly controversial but let's get into it sure what is a bad developer bad senior developer so most dichotomies are false having said that I will say I feel that there are often two kinds of software developers they're the ones who all the time are feeling like they don't know what they're doing and are asking for help and just feel like they're a little bit lost and that's me but then there are the ones that feel like they always know what they're doing and they need you to feel wrong and stupid because that's what makes them feel right and they love to argue and tell you what's wrong about everything that you're doing unfortunately being good at programming computers doesn't involve being good at talking to people all the time and so there is a subset of humans who have fallen into our career who are great at talking to computers like unarguably great at it but not so great at talking to people and I think bad software senior developers are those kinds of people I used to be one of those kinds of people I used to want to show you how smart I was all the ways I could and I wasn't smart looking back at it but I thought I was I thought I knew everything and you know I just slowly over time with more practice and more exposure to a lot of people who are much better than me I came to see myself in a much more accurate light which is no I know less every day because my I zoom out a little bit more every day and there is to know about that I don't know and so I think being someone who can comfortably say I don't know and help me understand is characters of a good more experienced developer and the bad ones say I do know you're wrong and this is the end of the discussion yeah pretty much agree with that and I generally think that there isn't really bad software senior developers but it's just really bad because you write code with other people unless you are working you're a rock star and you are building this product alone and bye bye yeah so it's just really just really bad I only work with senior developers who are just very bad team players yeah yeah arrogance and not being a team player so I think similar to what has been mentioned already I would any day hire somebody who is technically not as good as another candidate but they are much better communicator much better team player less arrogant and I have passed over really really technically strong candidates that are just really arrogant and I felt that they wouldn't get along well even during interviews their personalities were already coming up when they were challenging you even the interview feel very some people can even make you question yourself and that's not really the kind of environment that I would like to have in my engineering team because like you know like Shilin said programming is actually your team thing you write code with other people so you need to be able to get along with other people if you have this one very strong developer but you know starts pointing faults at everybody starts telling people how they should do their work even though it's none of his business or none of her business then I'm sorry you're just not the kind of senior developer that I want to work with respect to this is there a difference in your learning process from when you were starting out as a developer versus the you now with more experience what learning strategies do you feel is productive or effective definitely and I think I can give a concrete example when I was first starting out I think my primary way of learning was going through books that you know would kind of explain projects and frameworks all the way through in the context of sample projects for example or blog posts whereas these days my learning process will often involve something new falling on my radar for whatever reason a new library a language whatever and one of the first things I'll do is I will sit down and at least skim as much of the documentation as I can and my goal is not read it all, commit it all to memory perfect I can recall everything not at all that's impossible for me maybe some people have that gift I'm not one of them but what's useful about that as an approach that I found in my career is you give yourself the opportunity to remember something in the future if you just expose yourself to it at the beginning so if I know I'm going to be spending some time using some library I'll go and I'll skim through the documentation and then you know didn't I read this in the docs maybe and some of the time I'm right and I did and so there I just saved myself like 30 minutes of wondering if it was even possible or what the right way to do it was sometimes I'm wrong and I spend 10 minutes 20 minutes looking through the docs going no I know I read it here and then I can't find it but overall net positive in terms of time investment at the beginning versus by the end of the project learning is for me quite depends on your learning style so for me I'm more of maybe a kinetic kind of learner where I learn everything by doing and initially most of the ways that I learn how to do things even if I'm given a book I would just read the title and I'll flip the example and ah I understand it's magical and usually if I and then I will start trying to build a small little thing of this so for web application all the different kinds of frameworks that I'll just do the standard to do MVC and see if I like that framework if I do like that framework I'll go read the documentation on what's great what people are saying that it's great about this new framework but I think it's generally the same if I'm learning Docker I'll kind of look at some of the examples of how people write a Docker setup script and then say hey this is like something as easy for me to pick up and teach to other people yeah um for me I think um so there was a time where when I picked up something new like for example when I was learning Rails for the first time um I just looked up on blog posts and I think there was a really there's this like famous um tutorial about learning Rails where you build a block clone and they show how to create a author model and then you have to like this um blog post and then you have like a block entry um something like that I can't remember I think it's there's there's a whole website dedicated to it and there's a tendency to basically just follow the steps and do it and and like oh every step you follow you copy paste the code and oh it works you know you write it up type it out whole still came out like oh it works at the end of the day you have successfully built this blog app clone and learn exactly zero because it just works right you just copy and paste and everything works so um I think um one of the things that I started doing a little bit differently these days is when I learn something I would actually separately document and maintain my own set of you know like learning documents kind of thing and um sometimes I would just like try to mix it up a little bit change it up a little bit and I think it's um also nice that you know we have a lot of code that's easily shared is this like github um so I like to also learn uh through reading other people's code you know um taking notes about what I felt I learned so that you know when I go back to do something again I don't have to like oh how do I do that you know how do I scaffold a Rails app again let me go back to that tutorial and start from scratch everything again I just open my notes like ah this is why I should do this is why I should do that so it's kind of just at least for me a way of forcing myself to really understand what I'm learning rather than copy paste oh it works okay for the next thing yeah I think it's pretty important to learn the principles behind all the examples that you will see because like if you can you can see there are so many blog post application that there's so many ways you can build this application but why did the author choose that way of writing his code to build the application that it's more important to understand the principle behind it you can see a lot of this in style of flu answers where the people give the example of how to solve this solution but they also give you a nice explanation of why this is better as well just on the topic of learning before we move on there's something I have a strong opinion about this seems like a good time to share it a characteristic that I think helps separate junior from more senior devs is how well you know your editor I don't care what editor you use I really don't but I do care that you know it well learn the keyboard shortcuts not all of them because there's probably more than you can ever learn but learn the ones that you're doing all the time and this is a catch-22 in a way like okay Gabe well how do I know which ones I'm supposed to be learning how do I even know that there's a keyboard shortcut for that thing that I'm doing all the time if you don't know then you can't start using it in your life it's not going to be better just start noticing what you're doing in your editor a lot with the mouse and I can almost guarantee you there's a way to do it more efficiently and those things really add up and keep you in the flow so just whatever editor you're using just learn it like that is time well spent I have a story true story so when we were pairing back in Neil so back in Neil we would use Vim so a bunch of us use Vim and we use we're building a Ruby app in Vim and we're using T-Markz and I was pairing with Gabe and he was really frustrated because a keyboard shortcut that he knew would work usually works doesn't for me I really knew the company I was afraid to ask him like oh gosh can we just move on I really wanted to say move on but I didn't dare to say it but he persisted so what I learned from I persisted I managed to fix the problem and got that shortcut working and it was basically to run the test in a different T-Markz window remember that shortcut so you couldn't get it to work if you forgot what was wrong it was working so once that you got it working getting feedback from our test was much faster and you will be able to go through that the story really really fast so the proficiency from that experience I realized proficiency in your tools is important proficiency in your tools that you use is important in getting really good at what you do I think one more thing I want to add is don't be afraid to ask the simple question or one seemingly dumb question because sometimes a lot of people take for granted that you're supposed to know this and then you feel embarrassed if you don't know it and then you're afraid to ask I can guarantee you that I have interviewed a lot of candidates where I asked them a very simple question and I've lost count of how many times I've actually stumped people because everyone thought that it was a simple question that you're supposed to kind of know it but because I don't really know that thing very well I don't necessarily know all the technology so I ask you as this and you're like, yeah good question I don't know and if you're afraid to ask your colleague then there's always Mr. Google you can always ask Google and if you're afraid to ask Google because you're afraid later if you're googling something with your colleague and then they see it comes up in your history there's always private browsing so there's really no excuse for you not to ask a question also we forget things all the time even though senior devs right let's just level set for a minute just today and I've been programming in JavaScript for like over a decade just today I googled how do I remove an element from an array at a particular index because I didn't remember that it was a radar splice I looked that up today yeah always forget that can't tell the difference between splice and splice sometimes yeah so like don't think that you have to remember everything you're not a senior dev when you have to look these things up I googled like a hundred times a day stuff just like that I'm embarrassed to see all the tabs in my browser nope not the answer not the answer yes exactly yeah I lost count how many times I googled regex rules regex rules regex101.com is still the greatest site for interactively evaluating regex as you're writing that's cool alright so let's come up to some somewhat personal or directed questions this is director Jenny what is it like being a female developer in a male dominated environment what can industry do better well you know I guess both of you can answer if you wish so interestingly I was also having this conversation earlier today with another colleague and I it's not something that is just that is necessarily directed to women only but I think there's also there's a male-female divide and then there's also a junior-senior divide because I think a lot of the problems that a lot of women encounter I think in general if you were to just like rope into the issue a little bit I think to an extent any junior developer regardless of whether you are male or female who also encounter it so one one example would be when I'm okay let me rephrase that I think sometimes people kind of like assume that if you're a female developer especially if you go to meetups quite often I lost count how many times I go to meetup and somebody just ask me oh you're a designer, are you marketing are you accompanying your husband and I also I myself also end up feeling intimidated or I don't really want to go to certain meetups because I really don't want to deal with these kind of questions so that feeling of intimidation I think is quite similar quite similar in the sense you know sometimes you know you go to a meetup and you have all these senior developers or people who have already experienced talking about things and you feel like really intimidated and you don't feel very welcome regardless of whether you're a female developer or you are a junior developer sometimes you might feel as well I think what can be done I think the fact that this junior dev exists also is actually a very good thing and I think there's a lot of meetup events like tag ladies and so on that tries to encourage and create a safe space for women to actually get together, learn, talk together but I think the industry as a whole also needs to understand that really shouldn't matter whether you're a male or female what should matter more is actually your ability and your ability and your tenacity to learn something I was remembering a quite funny conversation I had recently there's a lot of events lately that are targeted at like gathering females to talk about technical stuff and it's a female exclusive event and it does get a bit tiring sometimes when you're at these kind of events where instead of talking about technical issues they are talking about feminist issues and I remember one of the conversations I had with other ladies is like man I wish everyone just stopped pushing feminist issues on the table instead let's push gay issues my hair jokes aside I don't think that in my experience as a professional I had not really experienced too much sexist comments or gender based discrimination but I did feel that sometimes in when I was in schooling probably more because everyone's more immature that when I'm inside a male or male group sometimes they behave like fred boys and they talk about very graphic things and sometimes they talk about they talk about they just talk about very male interests like soccer and video games I like video games but I think it's quite important like I don't know whether in some companies they do bring this fred culture on board that's where the programmer thing feels comes from and I think it's important for anyone whether you're in an all girl group not just to try to include the other party and get them to talk about their interests as well like if I'm in an all girl group I also get very bored of listening to people talk about Korean dramas all the time so I think it's very important to try to get to know everyone in your team it's important for bonding as well and better I think having these communities around you and identifying people who can sponsor you not sponsor in terms of monetary sponsor but sponsor your learning, help you along introduce you to other communities that are equally supportive that actually helps and I think just keep in mind also that there will always be people who will be pain in the ass if I'm not sure if I'm supposed to say that word on video yeah so there's always going to be people like that but on the flip side there's also a lot of people who are ready to basically support you, help you along provide a good environment and a safe environment for you and if you're in a company where you feel that you're not very well supported if leaving the company is not an option for you then you could try finding outside help or have somebody outside that you can help you along and give you guidance and how to navigate all these issues so this is a question for sharing as well so I will just go quickly to that what made you want to start your own company and what advice would you give someone who wants to open his own for me personally what I always wanted to do as a kid and what always drives me was to create value in the world and I think I was previously working at an ad tag company and I thought creating technology for people to serve ads is horrendously stupid I was also getting really really bored of what I was doing in my day-to-day programming which was basically create, read, update, delete databases, forms screens and repeat for different entities or new concepts and I got really really bored of that and I wanted to work on something new and interesting and Founder Story is more I decided to join Entrepreneur First and met my co-founder Eugene and we just both talked about how frustrating we just talked about how frustrating it was to test web application because the story is that back then when I was working in one of my previous company we didn't have DevOps processors DevOps processors is more of a modern thing in the recent years and back then what happens is when all the users are asleep the software engineers are awake and we will be ready at 2am to get the green signal from the manager to press the button that says deploy of course it's not just a button it's just that I run the command line too and do this, run this script and that script we were able to get the green signal and because our team we had a team in Vietnam who did testing manually and it was really hard to as we build more features on the application, there's two problems one is that the team cannot keep up with the testing workload and you cannot simply just throw more human beings at them problem of testing because there's a communication overhead now you need to communicate to more people about how that application is supposed to work and make sure that everyone has a consistent understanding and you can't just keep adding more people to the team so I kind of figured hey we need to create a way for people to be able to we need to automate our test we don't keep doing the same shit over again it's boring so I just told testers who one programmer say could you guys try some of these tools for automating testing for the UI and they basically say are you crazy, are you asking me to learn HTML, CSS, JavaScript Selenium this goes inspector etc etc you might as well just send me back to university because there's a lot of things to learn they were like okay I think we need to we need to create a tool to automate testing something that is easier for people to learn and one integrated platform my original motivation for creating my own company was that I wanted to create something of value and something that excites me as well as technically complex for me and exciting for me to build so what advice would I give to someone who once opened his own company I think the most important that's two very important advice I would give is one, you must validate that there is someone who is willing and able to pay for the product because you need to survive on money at that time you need to feed yourself so you need to first and foremost make sure that someone is willing to buy it's not your mother not your friend not your best friend but some stranger that you think is a potential customer go ask them if they want to buy a product and then build the product don't build it first, maybe you can build a prototype first but don't wait forever to build your idea and then find out that nobody wants it so that will be worth some time the other thing that I would advise is building your own company is really difficult and community support from co-founders from entrepreneurs so that you know that everyone is in the same sheet as you really helps because it motivates you because everyone is someone else going through the thick grasses with you cool, thank you and let's do a quick one with Gabe which I think you probably can answer very well what are you talking about? one of you, two minutes what are your thoughts? you don't want to pair on the answer mic? like old times sure peer programming it's a thing if you don't know what it is traditionally two people two keyboards, two mice one computer, right, one editor can be more than two people too they have mob programming where it's a whole room it's a real thing it's actually pretty interesting too what are my thoughts? it's really hard to do well it's not something that just intrinsically happens when you take two people who know how to program computers and sit them down next to each other and say work on this together, you're pairing you need to learn how to pair well and the way I learned how to pair well was working at Pivotal Labs or NEO and with other people who already knew how to pair well and they taught me, so I think the best way is to learn from somebody who already feels like they're decent at it there's probably other ways too, it's just that my journey was through direct exposure to people who already knew how to do it well I think it's great, when done well it's extremely valuable I used to tell people that when I pair, I have this laser focus that I didn't even know it was possible for me to have you're coding, you're in the zone by yourself sure that happens, but when you're pairing you there's this natural ebb and flow that happens when you're, at least when I'm working when I'm programming where my brain switches levels of engagement I know what I want to do I do it, and then I have to sit back and I have to think about what am I doing next or why is this not working because my brain was in like solutionizing mode and then I'm like, oh crap, there's an error I have to switch gears a little bit because my brain was already ready to do the next step because I assumed that what I just wrote would work but it didn't, and so now I've got to put that on pause shift gears, why is this broken when you have a pair this, you fall into sync and whenever you kind of pause and go like, I'm not really sure what to do next your pair is almost always ready to go I got it so I can walk away, take a phone call, come back he's still in context, he still knows the code I can get right back into it just as easily so this is good so when done well it's an amazing experience some people who don't like it say well, you know, I'm wasting time I'm having two programmers work on one feature at a time okay, yeah, but the code review is happening while the code's being written so you don't have to do that later you know it's getting reviewed because you're convincing your pair that this is good enough to move on you're writing much better tests because you've got two heads thinking about all the surface areas of what could go wrong what's not worth testing, what's not worth testing all that stuff so in general it's great but I also think it's not for everyone you don't necessarily need to do it all the time I don't think it's worth being religious about but it's a great tool to have and I encourage you to try it sometime if you haven't yet alright, thanks Gabe so you've got the answer let's click that decisions, decisions let's try let's go with this one let's end on the positive note what are some skills and traits to have to be a great programmer tenacity right, I tell a lot of people who are getting started with programming and who just like don't know anything about programming every day I oscillate between feeling super smart and super stupid right, many times a day and forth you have to get comfortable with those highs and those lows I just realize that you have to be comfortable being uncomfortable that's programming every day so having the tenacity sometimes I describe it as like you're just smashing your face into a wall until you manage to knock that wall down and then there's another wall, it might be one foot behind it might be 20 feet behind but you're going to get to another one you're going to smash your face against that wall until that wall falls down and that's the progress that you make so awesome and sometimes you feel like you beat your face against the wall a day but if you just stick with it you get shit done there's my answer I think the one best traits to have for a programmer is knowing how to debunk your code on your own I get quite surprised many times when I worked with Virginia developers and they told me, I got an error I don't know how to fix it then they said, okay what do you do last I did this and this and this last okay undo that then what, is it still broken? yeah it's still broken then undo your last step go step by step control seek step by step figure out how you broke your code first you can speed through it by adding things like breakpoints learning how to do it that goes back to know how to use your tools know how to use your editor a lot of editors come with very great tools such as the debugger so you should learn how to use your debugger and figure out how to read the stack traces and how to evaluate our variables live and to figure out it's a great place to catch all those weird strange, rarest constructions that only happen in certain scenarios by stepping through the debugger yeah take it one step one step up some more sometimes when develop opportunity first come to me and say like I've got this problem, I don't know how to fix it I don't know how to use the debugger and then I'm like okay have you tried printing it out first printf we tried to printf console.log and then they're like they try to do it and they're like ah there you are there you have your problem okay I think it's a good one time for one last question and I hope it's the highest one here let's see let's go for this one of course we all a lot of you here are junior developers it's understood that juniors take longer to code at the beginning, is that true I think it's a fair generalization I mean if everything else aside I think if you take somebody who's been programming for five years, somebody who's been programming for five months and you say here's your task just write me a simple thing where I can type a username in at the command line and it will find me the last 20 tweets from that person that mention other people simple program right, we could write that it probably wouldn't take too long I think that the senior dev is going to finish it faster than the junior dev so I think that in general the mark of a senior developer is recognising that a junior developer will probably take a bit more time and allowing that junior developer a bit more time I think me and Eugene we kind of agree that junior developers require six months to train at least to get through every single layer of our stack from back end to front end to CSS to JavaScript because the stack is thick and there's a lot of things to learn and I don't really think that you can learn everything by sitting in the office eight hours a day for three months and staring at the same layer of the stack you kind of need to slice it and investigate each of this then you'll learn how to code really fast but it's not a disadvantage or a problem it's just a natural cause of things I think personally I think you also have to resist the urge to jump in and just write code immediately because sometimes senior developers also take our slow at writing code because we spend more time reading code than writing code and planning for how should I design this piece of code and all that stuff so don't ever be urged like let's write some code let's take a step back let's take a look at this, what's going on here one last thing about that I think it was one of our colleagues Rahul who was talking about an experience that he had where the converse can also be true he was saying we hired him as a junior developer and he was saying at NEO he had this experience where he was working with a more senior engineer who he was saying wow there are so many times where we have a question how does this thing work and this senior person they just said let's find out and you write like three lines of code there are times where the right thing to do is if you can answer yourself by just writing code for a minute just write the code for a minute, make a little start a new file, write your five lines of code, run, question answered that is a characteristic of I think more senior engineers sometimes they're willing to go I don't know but we can figure that out very quickly let's do it sometimes we're quick to write code sometimes we think a little bit more I use IRB Ruby is here I use IRB to figure out how does this syntax work I'm too lazy to read the documentation it takes too long to load the page I'll just scroll right in I would even use tests to guide me along I use tests to I think this piece of code should work this way let's write some tests to verify that and then write the code if it doesn't, something is wrong yeah, that's cool I think that's all we have any final words from you guys? I just finally remembered one of the I was reading on dev.to that's a great resource it's really funny when they ask a lot of developers what is the greatest thing you enjoy about coding for senior developers is deleting code it's not writing anymore for all that we have talked today about being a senior developer how to become a senior developer what should you learn I think sometimes we also glamorize senior developers a little bit too much because I find personally a lot of my work these days is actually mentoring and coaching younger developers as well and sometimes I feel like I actually end up learning more from the junior developer in the course of teaching because sometimes it's just a matter of a fresh set of ice challenging a fresh set of opinions or thoughts about what you've already known so far this has always worked what changed things what if you try this wouldn't that be better and you're like it could be, let's try it out and it turns out that they are right so people are up to be a junior developer and when you do become a senior developer don't look down on the junior developers because they will also have a lot to teach you there's no such thing as a senior developer I have two parting words, this is one of them there's no such thing as a senior dev I think we can all agree there's a state where you're a junior dev and then there's a state where you feel like you're no longer a junior and then it's just relative it depends on the context sometimes you're going to be no more than the person next to you sometimes you're not you'll feel comfortable saying I don't feel like a junior dev anymore but that's really it the other thing that we didn't talk about but I think it's worth a quick two sentences or so imposter syndrome that's something we talk a lot about in the industry for those of you who don't know maybe I'm going to mischaracterize it but I'll try and get it right it's that sense that you're succeeding because everybody's fooled you really don't know anything about what you're doing how did I get this job? they haven't figured out that I'm an imposter yet and a lot of advice that junior developers here is that's imposter syndrome talking don't worry about it I also want to say that it's not necessarily true that it's always imposter syndrome at the beginning of your career as a software developer it is fair that a lot of the time you actually don't know what you're doing and you should embrace that don't dismiss yourself going you think oh I don't know what I'm doing no no no I do know what I'm doing that's just imposter syndrome I remember reading about that sometimes you don't know what you're doing and so the real way to move forward is to just always be getting out of your comfort zone and checking it with other people what do you think about this what do you think about that here's what I think so don't work in isolation try and work with people who you feel are better than you don't come to junior dev anymore and don't always assume that a senior developer necessarily knows more or better than you yeah we don't yeah most of the time I don't know what I'm doing yeah but great anyway thanks Gabe, Shilin and Jinny for a very insightful Q&A I hope you guys learned a lot in this whole hour plus so it's a bit long so thank you for staying so late before we go on there's one last thing this is something I've been trying to work out and create this is something that I've talked to Gordon who runs a program at ThoughtWorks called ThoughtWorks Jumpstart where they actually bring people to a 12 week program so what he has approached me and said hey we should try and collaborate and do something together so one thing we'll be talking about is this thing that we're trying to do like more hands on sessions because from the last few surveys that we have conducted I see a lot of you wanted to do more hands on sessions mentoring you really want some people to teach you things like pair programming and stuff like that so this is something we're going to try the first one will be on the 30th of June we'll be at ThoughtWorks on a Saturday so we'll create an event on our meetup page soon but essentially what we want Hope to do is come together and do some coding together learn some code there will be some ThoughtWorks who will be sharing with us their techniques and ways of doing this oh Gordon you're still here I didn't realize sorry so yeah so Gordon you want to share a bit more about that yeah before I talk about my idea we have to do some quick surveys just to find out whether I'm Gordon I'm working for a company called ThoughtWorks so let's do a few quick surveys one survey is how many of you feel that you can still improve your coding skills let's go I see a few people who didn't read your hands okay then the next question is how many of you feel that you can commit 3 hours every 2 weeks to improve your coding skills it's still a lot of people it depends on 2 weeks and okay one more question how many of you have heard of the terms like coding kata coding dojo code Richard still a lot of people I'm very happy I'm in the right place so the idea I was having is to probably conduct some hands on coding sessions every 2 weeks on Saturday afternoons probably 3 hours and the way we will probably just practicing our coding skills either format of coding kata coding dojo or coding Richard the target is probably practicing the program solving skills maybe some pair programming skills and also the TDD or refactoring skills so through those exercises you will become a better developer we will start from this and we will continuously getting feedback from the attendees and to see how we can improve it or what content what format we need to change also for those who didn't read your hands feel free to join us because we are awesome developers and you can be there as teachers or instructors ok that's it as Michael said we will put the venue and the timing and the details on the website meetup website you can start to attend the events are you guys excited about that? cool right? awesome thanks so once again that's the end of today's meetup