 Det är bra att vara tillbaka och se så många familjelfäser och så många nya. Jag heter Ted, för du som inte vet mig. Jag jobbar nu som VP av engenering, men jag har en bakgrund i läge. Jag har tidigare att lägga till högskoliga barn, mat och fysisk. Jag jobbar nu för en startup som heter Engaged Rocket. Vi bygger HR-produkt-svets utav Block 79. Om du tittar på en jobb som en junior-developer och är intresserad av att lägga mer om det particulara som vi har i vår company, kan du inte tala till mig efter presentationen eller kan du pinga mig på många Singapore-slekt-channelser. Jag är också intresserad av lokala kommuner. Vi tittar på speaker för Ruby SG. Om du är intresserad av att tala kan du tala till mig eller William eller Daniel efter presentationen. The Tech Ladies Bootcamp är tittar på mentor och coacher. Om du är intresserad av det kan du tala till... Inte Elischa, men det är en gädda för honom. Jag är också på teamet RUBOCOP som är en städig kodanalysisk tool för Ruby. Vi tittar på nya kontributörer. Om du är intresserad av open-source, men du vet inte hur det börjar och du vill hjälpa dig ut, kan du också komma och tala till mig efter presentationen. Det här talet är om hur inte att bli en senare utveckling. Det är inte att bli införd med hur inte att bli en senare utveckling. Det är... Just inte att göra det. Det här suggests att det finns många rapporter och att de kanske blir bättre än de andra. När jag skrev den här presentationen, kom det ut som en sorts stream av konstnössing. Det ville inte vara någon annan format eftersom idéerna innebär lite intervjuad. Jag försökte att göra det som möjligt som möjligt. Och vad jag vill göra är att röda lite om hur jag reagerar på mitt jobb som en vp-ingenjörer och på jobb av våra programmer och vårt field i generell. Och några av dessa idéer kanske inte ska användas direkt och det är okej. The point is not in the details of the ideas really. It's in the reasoning about the ideas. And I'm hoping to help you get a bigger picture of whatever context you're working in right now and your journey to becoming a senior developer. So the talk might be slightly mislabel because I will only talk very briefly about how I think you should not become a senior developer. So one of the most popular and according to me probably the most incorrect way is just list out a number of technologies that you should learn and then once you reach the bottom of the list you are a senior developer. So I understand that the idea is extremely compelling because it becomes a journey that is bite-sized and gamified and it's just about memorizing new tools and because we are developers we tend to have high learning capacity and a keen interest in what we're doing so the prospect of just learning some new frameworks or tools is very compelling. And I'm not saying you shouldn't learn any technologies. Of course you need to know something to be able to do work but I think about it as a prerequisite so I like to say that it's required to know these things but it's not sufficient to do a good job. And I don't place too much confidence in better tools. History has shown that better tools tend to allow us to be bigger and more complex software just as poorly as we were able to build smaller and more simple software previously. And the only thing that creates better software is improving the people. So as a disclaimer this is some repo that has a developer roadmap and I don't know the person who created it and it's a great thing because it works as a reference for sort of what the ecosystem looks like right now in terms of technologies. So you can use this to get an overview but I wouldn't treat it as a roadmap to becoming a senior developer. It's probably a roadmap to something else if you follow it blindly. And that is a trap. And that trap is called expert beginnership. So if you've been in teaching or education the bottom part is the Dreyfus model of skill acquisition. And when we reach the advanced beginner stage and this is a stage of just accumulating facts and putting them inside us. We sort of see a fork in the road and one of the paths leads on to be more competent and beyond to become an actual expert. And that path involves getting the bigger picture of what we're doing. But there is also another path which is the trap into expert beginnership and that is treating it as ourselves as sort of a bucket that just needs to be filled with more and more low level implementation details. And I think that this simple accumulation of facts is not really enough. It has been talked about in the terms of just more and more content but just letting the ideas pass through us without interacting with any of our reactive parts isn't that hard. And we need to let the ideas sort of transform our understanding of what it is we're doing. So I show hands who knows about continuous integration. Who does continuous integration at work. So continuous integration is the act of bringing the teams systems together and making sure they work together. But what is it we're actually integrating out? It's not really code because that's just making the characters work together. We could argue that we're integrating our systems but when we do continuous integration I like to think of it also as an integration of ideas and I extend this concept to myself as well. I constantly need to integrate the ideas of others with my current latticework of ideas. And I like to think of this as laying a latticework or weaving sort of a web of ideas. And I think as a junior developer you have an advantage here because you can look at your seniors and you can look at this web and you can see these are the really nice parts. I'm just going to take that and integrate it into my own. But you can also see the thorny parts where the ends don't really meet in my understanding and in my integration of ideas. So you can use that as a counter example and say oh, Teddy is really contradicting himself on these things so I'm going to avoid ending up there. Whereas for me who has been doing this integration of ideas for a very long time, changing that part might take a lot of work. So just be critical. And by critical I don't mean being close minded. I come across junior developers who tend to reject everything until they have sort of experienced it themselves or inferred the things from first principles. But I think this is a bit of a waste of the potential of having mentors and having seniors around you who have experienced things and who can warn you about certain missteps. And then of course pick up the ideas that are the best ideas you have heard of so far knowing that you will come across something better and then be ready to drop it. So that is actually everything I will say about what not to do. So the rest of the talk I will dedicate to talking about things we can do instead, how we can reason about our work and I think reasoning about our work is how we can get better at it. And this will hopefully eventually allow juniors who are at the advanced beginner stage to graduate the competent stage. And I like to start this part by asking a question. So the question is how long is a string? And if you have, if you think that this question is nonsensical, that is on purpose, this particular question is a rhetorical device that's used in my home country, which is Sweden. And we use it as a retort when someone asks a question that doesn't have enough information or enough context to be answered in any meaningful way. And it's often paired with another saying which is the way you ask the question is the way I will answer it. And although we all can seem to agree that this question without any supplementary information is quite absurd, we see people ask questions like this seriously and people trying to answer them seriously. But this question is equally absurd. We could approach it with sort of an empirical mindset and say that well if there was a best programming language one would be using it and there would only be one, right? Which is not true. Or we can approach it with a rational mindset and see that programming languages seem to necessitate certain trade-offs and how we value those trade-offs determines how good it is or not. That is to say it is a subjective valuation. And the third and absolute, the worst option approach it with an emotional mindset where we value our own attachments or affiliations with certain programming languages. And to me it seems like the first option is the best one. Having the empirical mindset we can look at outcomes which is a very powerful mental model to have to reason about the outcomes that we're looking for. A lot of times we don't really have enough data to make an empirical judgment and we need to resort to the rational mode of reasoning about things. But reasoning about things is a very thorny place to be because human reasoning is fundamentally very flawed and especially when the emotional part comes in as well. So be very careful that rationalism can very easily turn into sort of religious dogma as well. But if we're given the choice I prefer to never have feelings about code or feelings about ideas because it seems to be a dead end to me. It sort of locks me in. So whenever I find myself typing in a code review I just tend to stop myself and say why am I feeling anything about this very objective piece of the system. Because it probably means I had some unexplored things there. So be candid and question things objectively whenever you can. I'm going on with the questions here. Is JavaScript a bad language? Who has ever proclaimed that JavaScript is a terrible language or made jokes about it or used it as an icebreaker? Okej. So most likely the reason for that was emotional. We had some bad experience. Either first hand or we heard a story from someone else about how bad their experience was. But if we tried the other mindsets empirically JavaScript is a great language because tons and tons of people are using it successfully for tons and tons of things. If you try the rational mindsets we can sort of start to articulate what are our gripes with JavaScript. So we can look at what it's used for. We use it for UI. So it's evented, that's cool. We have events in UI. But it's general purpose and UI is sort of a specific application. We do with something more specialized. It's imperative which is not so nice because UIs tend to lend themselves to a declarative approach. So then we can revise our judgment that it's a bad language into it's probably a bad philosophical fit for UIs for the web. But it could be a great language if you are building a heavily evented and streaming system for example. So it sort of unlocks the trap of that emotion where we look at a word or a name and we have a negative emotion and then we just try to avoid it. And I think abandoning these emotional valuations and resorting to reasoning or empiricism can yield some very important insights. So if we look at this question and we start exploring it it leads to a very important insight that programming is not really one single homogenous discipline. And just because the different disciplines share the common denominator that we write code doesn't mean that they have the same challenges and constraints. And I think we should consider them different disciplines as a whole. And if you are a games programmer maybe you need to know linear algebra by heart. If you are a web developer maybe you don't need to know any linear algebra but you need to understand the business domain and you need to be intimately familiar with user behavior. If you are building embedded applications maybe you need to be on top of memory management and CPU cycles which is wasted effort in other applications. And I like to even say that programming is not about code that much and that might be heresy. Who is this guy saying that programming is not about code. There is this t-shirt that says that programmers are people who turn coffee into code and all true wisdom is found on t-shirts. But I think programming is about code in the same sense that writing is about words. It's just a means that we use to express our ideas and what is important are those ideas themselves. And I think programming is about systems in the same sense that writing is about stories. So just when we're at it this is not really a junior developer question this is like I want to be a developer question. So which language should you learn first? Any takers? Is there one question? It could be yes. Who said that? Just send me your resume after. You should learn English because really we're translating problems and ideas from natural language into code. And if we cannot articulate those problems or ideas in natural language then we have a really bad starting point. It doesn't matter how good we are at writing code. So after you learn your first language English and your first program language what should you learn next? Maybe, maybe. If you are into 3D programming then that might be a good idea. But as William pointed out it might be the wrong question We need to ask what I want to do what problems am I solving what kind of programming do I want to get into. And don't accept run of the mill universal answers to questions like this because there tend to be none. To explore this a bit further we do a show of hands again Who here would say they work in a technology company? And who would say they work in a product company? I have no idea what the rest of you are doing. There are no more options. What I like to differentiate between the two and by technology company I tend to mean a company where new technology is invented and where the primary constraint is the technology and by product company I tend to mean companies where we take existing technology and we assemble it into a product that solves particular problems for some field. Yes! So some large companies do both so Google is the most prominent example right? They create the technology but they also build products from it because they are large enough to be able to do everything. But because the constraints and the challenges are different what's required from you as a senior developer is different. So there is no one path to senior developer ship. And anecdotally I think this means misconception that programming is a single discipline can lead to a sort of lack of work satisfaction. So I met a lot of programmers who are quite unhappy and they are jumping from product company to product company and they are very into deep technology and they don't realize that these companies that they are joining are not like gated playgrounds where you can work with deep tech they are doing something else they are solving other problems. And these product companies tend to be rather open business almost arenas that have human context that might not be interesting to those purely interested in tech. So I'm going to go on and talk about product companies so if you work in a technology company feel free to follow along. So I like to think that all product development is integrated and that is because products have many interfaces so a product interfaces at least with different markets and with different users and with technology. Which is why we have different teams for dealing with those different interfaces. So we can have a product owner who interfaces with the market we can have engineering team that interfaces with technology and design team that interfaces with users. And these tend to answer different questions so the product owner the designer can answer what should it look like and the developer says what is the best approach to building this. And that work is sort of done in isolation but I tend to think that the real magic happens in the intersections or what I call the arenas. So for example if you have product and development come together product knows how valuable something is and development knows how hard something is to build and then suddenly we know what is the return on investment for building a certain thing which informs when we should build it or in what order. But this requires us to understand the objectives and constraints of the other functions as well. Because if we don't understand their objectives then we cannot make the right compromises or we cannot negotiate when it's appropriate. But of course we should obsess about our own objectives the most because those are the ones we need to defend. So what then is the objective of the development team we could be misled to think that it is value because value is our deliverable but products are already obsessing about value so that seems wrong if our objectives are the same there wouldn't be any need for negotiation in the first place. And I tend to think the objective of the development team is flow that is we deliver value today and we deliver it continuously and indefinitely. And I think we should obsess about that. And the biggest threat to flow and the greatest enemy of the development team is complexity and I think all complexity added to our codebase needs to be thoroughly examined and tested for necessity before we commit to it. This means that solutions to four problems are big no-no and that applies even if it means adding our own favorite technology to pattern to the problem. Because we all have pet solutions and technologies but as professionals we need to sort of stuff them into a drawer and wait until the right problem calls for it. Because all solutions also come with their own problems and there are no such thing as a free feature or a free framework. So I use this chart with business people to illustrate practical trajectories for flow. The red line sort of illustrates what happens if we cut a lot of corners early on in order to achieve some short-term delivery. Maybe we're not writing any tests we're not really doing any modeling we're just focusing on grinding out features. But if we ask the product owner in one month from now would you like eight units of value or one unit? They're gonna say eight units. And it's important for us to protect our objective of flow and explain to the product owner that if we do that we're screwed already. Which brings us to another question I'm doing these questions just to make sure you're awake. Assuming we took the red pill and now we're knee-deep into the complexity depth and everyone is miserable is it better to rebuild the project or to salvage it? So we can do a show of hands How many think it's better to rebuild? How many think it's better to salvage? I've tried both several times and I will tell you the answer. So the answer to the question is it better to rebuild or to salvage is no. I can tell you that both are extremely miserable experiences and they are demoralizing and soul crushing It's not something you want to go through. So the answer is for us to sort of maintain our professional integrity and defend our objective before it can happen. And this is extremely hard and it can't protect us from legacy code bases that came in from elsewhere but I think it's the only way to be part of the solution. So in practice this involves deciding on some what is our maximum tolerable depth level and make sure we don't exceed it. And I think this is mostly done by making good decisions in our day to day work and I am a strong believer in the compounding effects of small improvements and the compounding effects of small regressions is equally powerful in the other direction. And there might be short stins of cleanup but don't buy into the don't buy into the myth of the big bang refactoring because it never works. Because refactoring requires very deep contextual knowledge of the parts of the app you are working on so you can't do like bread refactoring. You have to go depth wise. And it requires to have all the details loaded into your working memory We need to ask ourselves when we accrue depth why are we doing it? And this is Martin Fowler's blog So it sub divides depth into reckless or prudent and inadvertent and deliberate. So you can see reckless deliberate is saying things like we don't have time for design which is abandoning our objective in favor of some other other objective. There might be reckless inadvertent as Junxi said this is where we need to ask questions to our senior developers because we don't know what we're doing really. It can be prudent and deliberate saying we must chip now and deal with the consequences and the keyword there is deal with the consequences which means we need to negotiate with the product owner. Yes we can deliver next week but then we need some time to recover from the depth that we incur. There's prudent inadvertent we didn't know that it was going to go so bad to this approach. And as I mentioned product development has an acutely human context and at some end of the chain humans will interact with the product and even if those humans are other developers they are still humans as well. So if you look outside your own product team there is a sea of stakeholders that usually our product owner will protect you from by being the authority on what to build when. And these stakeholders they provide their candidate problems for us to solve. It doesn't mean that we will solve all of them. But what they do having common is that they are human problems so they tend to be unconstrained or any form of logic or reason because that's the nature of human problems they tend to be fuzzy. And this matters a lot because getting the problem right is the hardest and most important part of the job. And getting it wrong often means imminent defeat regardless of how beautiful the solution is or how flawless the execution because we were not solving the right problem in the first place. I don't think you need to think like a computer so there was this trend in computational thinking and algorithmic thinking I think mostly you need to think like a human and define them and frame them properly so we can solve them. And is to take ideas from the natural language that you use and turn those ideas into code. Mostly we need strong conceptual thinkers so focus on that. And because we are solving human problems which are fuzzy and not well isolated and defined like the problems we receive in school there is no magic formula really to follow and it doesn't really help to learn algorithmic thinking and in a way this is very nice because if programming was deterministic it would be a paradox in itself programmers tend to automate things so if programming was deterministic we would be able to automate it and we would have automated it and we would be out of jobs. So I like to show you this mental model which I use to make sure that we are solving the right problems which is the most important part so I consider three parts of any effort I consider the diagnosis definition and the framing of the problem the prescription how we intend to solve that problem and the execution which is just typing on the equivalent and I consider them in order of importance this is like orders of magnitude from the left to the right and I think it again it shows the relative insignificance of code it's just committing the ideas that we already generated in the previous steps into code and it's those ideas that matter but you should be fluent with your programming language which is not that hard compared to all the other things we do so it just means read up on the standard library and on the language syntax so they can use it fluently to express ideas just like you would in English but don't be tricked into thinking that is what makes you a good developer so just like learning the entire English dictionary doesn't make you Hemingway learning Ruby's standard library does not make you brilliant at coding and execution is still important and this has to do partly with credibility so Ken talked a bit about spelling errors in the newspaper and it doesn't kind of doesn't matter how relevant the story is if it's all with spelling errors the credibility is already heard so don't abandon it try to improve your execution with every task and this is usually people can get a bit annoyed with sometimes oh it's just an implementation detail and what I mean by that is we have already gone through the process of diagnosis and prescription which are the interesting parts how we type out the code is not that interesting to me ok in the interest of time my own guidelines as I just discussed I think better humans beats better tools every time and I think technical competence is required but it's not sufficient I think what lies beyond technical competency is what sets you apart as a developer always think about constraints if you do web applications and you're thinking should I do this language level optimization to my Ruby code the answer is no because the constraints of performance is I.O and the constraint of your team is developer resources if you're trading very valuable developer resources for very non valuable work but also think about constraints in your organization and your team especially if your team is the bottleneck because then we need to utilize our effort wisely obsess about flow make sure you're solving real problems this is probably the most important one and don't have feelings about code so these are just my guidelines you should probably develop your own guidelines as you go along so whenever you come across an idea that integrates especially well with your understanding of our work then make it your own and I think finally we need to beat the stereotype so programming is not manufacturing and you are not part of any manufacturing economy and there is this stereotype of the code monkey and we don't want to be code monkeys and being the big monkey does not mean knowing the most tricks and I think the best antithesis to the code monkey is credible discerning and reflecting professionals and professionals who holds and protects their own objectives and who know when to negotiate and when to compromise and one who can tell conceptual issues from implementation issues and reframe the problem and propose other solutions and I think it's developers who know what they know and what they don't so we need bold developers as in bold not bold and of course for everything else there is always that's all