Winston Teo is the Founding CTO of Jolly Good Code, a boutique, software development consultancy in Singapore. He has also organized the largest Ruby conference in Southeast Asia since 2013, RedDotRubyConf.
In this Codecast, Winston generously shares his journey moving from a large company, retraining himself toward becoming a viable software engineer, landing and learning much within a smaller startup atmosphere, and navigating forward to found an agile-based consultancy. He talks about his joy for teaching Ruby on Rails, building products for clients and understanding the importance of key, soft and technical skills to enhance one's work as a new developer in the startup realm.
Key Theme » Build for Resolution
"Engineering is always an expensive task whether you’re doing it yourself, or you are getting somebody else to do it, right? It is not cheap at all, so you don’t want to waste engineering hours trying to figure out what’s right or what’s wrong. When you go into engineering you want to make sure you are at least 50 to 80 percent sure that this is what you’re trying to build because it would solve that problem that you had earlier. I think that is really, really important which is why you probably find a lot of lean principles coming in where people teach about how to do design thinking, how to actually go out to customers, get feedback, etc. I think these are necessary skills and principles that you should know about, too – before you embark on actually building the application itself." – Winston Teo
"...when you step into the real world it’s not so much about (solely) making the code work...another thing developers should pick up is also to learn about testing – and you don’t ship if you don’t test your code. Because if you do, you’re just going to cause more problems down the road."
"I think ultimately what I always share is you need to care about a lot of things. You need to care about your users, you need to care about your products. But you should also care about your team and you should also care about your code."
"I always have the principle of try not to 'own' your code – in the sense of, let other people have a chance to read your code, understand it and make changes to it. In this way, you will improve and be a better engineer because you would read about what other people are trying to do, what they are trying to change...if you practice all of this, it will lead you to become a better engineer."
Full Episode » Transcribed
Hello everyone, welcome to the Viking Codecast. To everyone who’s listening, thank you for joining us. This is designed to be an interactive chat so we’ll have plenty of opportunity for asking questions and getting your feedback and your thoughts. But first I’d like to just quickly introduce our guest Winston, and am I pronouncing it right, Teo?
Well thank you for joining us all the way from Singapore. Winston’s the founder of which is a software consultancy in Singapore. He’s been doing agile and test-driven development previously with Pivotal Labs, I believe?
Yes, that’s right.
Among other things and have been a startup founder and engineer, I know we have a lot of cool stuff that we could dive into. In particular, your experience around startups for new developers looking to get into startups or joining startups is a really cool avenue that we could explore. But first of all, I just want to say again welcome and thanks for joining us!
Thank you for inviting me.
Of course - so just to kick things off, it’s usually good just to get a good understanding of how exactly did you get to where you are. Maybe if you wouldn’t mind, what got you into this field and what’s your path been to where you are right now?
Right, so a background about myself - I graduated from my university about ten years ago. At that time, in Singapore the startup industry was like pretty much nonexistent. So any of the companies that came to universities to do recruitment, one of those big companies like IBM, Accenture, HP, and stuff like that. So there were a lot of us who wanted to get a job after university, sort of went toward the direction of these big companies. I wasn’t an exception, I joined IBM straight after I graduated. I became a Database Administrator. I was outsourced to Singapore Airlines, actually, and I managed 200, 300 databases. Oracle, MySQL and other kinds of databases.
What I did during those times is basically just installing, uninstalling databases, running scripts for application teams and resetting database passwords every three months – because that’s the protocol, standard protocol for security measures.
Shifting to startups from a big company.
After about one to one and a half years I sort of got bored because this really wasn’t what I had in mind. I really liked programming when I was in school, so I felt I really should go back to do more programming.
I really wanted to join a startup because I think that’s where you get to learn a lot more things, rather than just being a small screw in a big company where you only do very, very specific tasks. I wanted to have a breadth of learning so I decided to look around for startups at that time in Singapore which I could join. One of the startups I joined is called WeGo.com. They are sort of like a travel search for flights or hotels, think of it like Kayak.com.
When I joined I actually got the opportunity to then learn Ruby, so that’s when I started to pick up Ruby and Ruby on Rails. I was given the task to build a stand-alone analytics application for the entire company.
You might be asking, "why don’t you use Google Analytics?" At that time it was about seven or eight years ago and at that time actually Google Analytics wasn’t good enough for our use, which is why we built something from scratch.
So I spent about two and a half to three years building that out and growing myself in the company, and eventually became a Product Manager. At that time, Pivotal Labs came to Singapore and decided to set up a center of excellence and I was sort of headhunted to join them as one of their first engineers. It was really a lot of thinking on my side whether I wanted to join Pivotal, I was already a Product Manager. Like I mentioned, when I was talking about the dreams of all graduates of university. The end was to become a product manager, maybe go up the career ladder and become an administrator of sorts in a big company. So I really wasn’t sure if I wanted to become a developer again, it felt like a step back.
But I started to look up what Pivotal is all about, what kind of engineering practices they do and I was very intrigued. They do pair programming, they do test-driven development, they do all these things, agile development, extreme programming. I was like: "oh wow, should I really join them and learn these new things and become an engineer again?"
After reading a lot of stuff online I decided, "okay why not, let’s give it a try." I joined Pivotal Labs in Singapore and it was really the best choice in my career so far, I felt. I got to learn so much more about good engineering practices. How to do pair programming right. How to do test-driven development right. How to approach projects in an agile mindset. I really learned so much in that three years, I felt I was pretty lucky to be able to learn all these things without having to step into San Francisco at all!
Building his own startup consultancy.
I decided to start my own consultancy after that, that was about two and a half years ago. I felt that I really wanted to reach out to other startups of smaller scale and to be able to work with them and help train them in all of these job practices that I know of. Which is why I started Jolly Good Code and I started doing more things other than the regular engineering and programming stuff.
As part of Jolly Good Code we start off doing a lot of things. First, we help startups build minimal viable products(MVP), so that’s engineering work for me. We also do pure agile consultation where we only go into teams with already established tech processes, where they are looking to transform and change the team so they can do more agile stuff. I also do pure classroom training – so Ruby, Ruby on Rails. I have conducted public courses for like two weeks just to teach Ruby, Ruby on Rails. I have done corporate lessons as well, for companies who were on Java but they wanted to change their developers to become Ruby developers. Then, we also build our own internal products. Of course, on the side – I do a lot more community projects. I run the Ruby meetups in Singapore and I also organize the RedDotRubyConf in Singapore for the last four years.
The RedDotRubyConf just ended in the last week actually, or the week before. A lot of videos are already online, you might have seen people tweeting about it. There are a few talks that are pretty good and I think it has gotten quite a number of retweets on those talks.
So that's the description of my history so far, and that’s where I am now. As far as Pivotal Labs, as far as with Jolly Good Code I’ve worked with a lot of startups. I’ve worked with a lot of corporates as well, and I’ve seen a lot of developers. I’ve seen a lot of project managers. A lot of experience came from all these daily interactions with them. Probably today I could share more about how you could become a better programmer for a startup, and moving forward after you have graduated from Viking Code School.
Awesome, thank you so much! I think what I’d like to focus on just to kick us off is two of the transitions that you had. One of them was basically around Pivotal.
One of them it sounded like you moved from the larger more established more enterprise-y world towards a much - and also, via a bit of product side, as well.
What were the big shocks that you got or the major changes that you saw moving from the much larger code bases to moving over to a place like Pivotal where things are much more rapid and the clients are generally on the smaller side of the project, or seem to be on the smaller side than what you were working on before?
So when I was with WeGo, actually it was still pretty much a startup – the code base I would say it was more of a legacy code base, rather than large code bases because there are a few developers who were working on the product already.
Developer sustainability, maintainable code.
I guess the biggest shock is you could actually do sustainable and maintainable engineering. What do I mean by that?
Before Pivotal and after Pivotal – during the consulting and stuff like that – I have seen a lot of companies who don’t employ sustainable engineering. People have a lot of "death marches" (laughs) – they work long hours. So that’s one.
And the second thing is maintainable code – a lot of people direct test. In fact, I myself am guilty of that while I was with the company, before Pivotal. The code works, but there are no automated tests, so I test them manually myself. What happened is after I joined Pivotal, they introduced me to the concept of test-driven development.
Not everyone has to do test-driven development, but it introduced me to the concept of tests. Testing is important and testing is the thing that helps your code stay maintainable and it allows you to take holidays without feeling guilty as well because anyone who looks at the code will probably have a better idea of what you were trying to do, versus trying to guess what you were trying to do. People would have no inhibitions about updating a code if they need to.
So I think that’s really one of the main things I learned, between coding in a very "rock-star" style, versus coding in a very process-driven, good practices style. Right now, whenever I talk to engineers that is one of the things I emphasize, too. Because I found that in university, and I think code schools generally do teach this now, but if you come up from the traditional universities I don't think they emphasize that much on testing.
It’s more about, "let’s get this thing out working, it works then I’ll give you a grade for it." But when you step into the real world it’s not so much about (solely) making the code work. I think that is one of the primary responsibilities of an engineer – the code should work! But at the same time, another disciple developers should pick up is also to learn about testing – and you don’t ship if you don’t test your code. Because if you do, you’re just going to cause more problems down the road. Even though testing does take more time, it is time well spent. In fact, in the long run, it will definitely give you a lot more benefits over the time that you have spent writing the test in the first place.
It’s actually, probably a good idea to give us a window into what it’s like to work at a place like Pivotal, which emphasizes all these things that you’re talking about. Then maybe we can focus on what happened afterwards. So what’s it like?
Pair programming experience at a startup.
Oh it was intense! Before I joined I heard about this thing called pair programming so I wasn’t sure if it was for me. Some of you may have tried pair programming, some of you might not have tried it before but essentially, what pair programming means is that two of you will sit down side-by-side and work on the same piece of code together.
So you might be staring at the same screen, or you might have dual screens but you would have your own personal keyboard, you would have your own personal mouse. For eight hours a day you will be doing coding with your partner, with your buddy, and that’s what Pivotal used to do. I hope they still do that, (laughs) I’m not sure what their processes are right now, but that is what I was doing every day for those three years that I was with Pivotal Labs.
Project workflow example.
If we got a project, we would start breaking it down to stories, putting it into Pivotal Tracker and we would have daily standups. We would work off the stories in Pivotal Tracker. We would code with our partner, do it in a test-driven development manner, ship it out, get acceptance, get clients to look at it, do retrospectives every two weeks depending on what the schedule was like. We'd keep getting feedback from the clients on how to improve. That’s really how we worked at Pivotal.
So after doing that for, I think you said three years, what made you transition out of that? Why did you decide to start your own thing?
Chosing to become a startup founder & educator.
As a big consultancy, there are some restrictions on what they can do and what they cannot do. Like I mentioned, I was there for about two and a half to three years and I felt I wanted to be able to reach out to more smaller scale startups and to be able to advise them on what could be possible in terms of planning for technology, planning for architecture and most importantly – how they could have good engineering culture that could make their engineering work sustainable and maintainable from then onwards. Being part of a bigger consultancy didn’t allow me to reach out to them as easily as I could have.
At the same time, I was really passionate about training, doing pure classroom trainings for Ruby, for Ruby on Rails, because a lot of people came to me and were like, "hey I want to learn, where can I learn?" The only thing I could point them to were online resources, at that time.
I felt, I really like teaching, as well. so that was something I would like to do which I couldn’t possibly do as part of a bigger consultancy. Also, the other reason is I wanted to do more community work – in the sense of running the meetups, running the conferences. And honestly, running a conference is a full time job (laughs)!
It takes a lot of effort and a lot of work. When I was with another company and running the conference, I didn't feel good about it because sometimes you have to take time off to actually make sure things are going well at the conference, etc. So moving out into a role that I had autonomy and purpose for myself allowed me to actually do some of these things much more easily, which I why I decided to move on! (Laughs) So I could actually do it and have the autonomy to decide.
Awesome! So what I would like to talk about next is the engineering practice in working with startups and specifically the kinds of projects you’re taking on and things like that. Before we do that I wanted to put out the call for questions.
I have a question - what was your light bulb moment where you felt confident that the test you were writing had adequate coverage?
Okay, so in the very beginning it was more of talking to my partner who was pairing with me to be like "hey, is this okay? Is this good enough for us?" And then when it was good enough we sort of moved on.
More insights on the benefits of testing.
When I started to code by myself, on my own, I guess the benchmark is always when -- you are sort of like: if I throw away my code and I only have my test left, I must be able to rebuild my system based on the test that I have. So whenever I look at my test, then...like I say...why do we write tests? There are a lot of reasons so to me writing tests is about accountability, about testing a code making sure it’s correct, it’s about maintainability, at the same time to me it is live documentation.
Testing as its own "live documentation" practice.
When you do agile and stuff like that you’ll find a lot of people say, "we don’t really need to do any documentation," that’s not true. You still do documentation, in this case testing with live documentation is documentation that never goes out of date. As soon as you make changes in your code you will make changes to your test, whereas if you write physical documentation or documentation in Microsoft Word when you change your code, you will probably forget to update the documentation so it will be outdated – as soon as you write it.
Test to me is something that is live and is always something that you have to maintain and make sure it’s relevant and correct to your code.
If you can throw away your code (laughs) - I've heard of this story before, right? So let’s say there’s a fire and you can only take your code or your test. Which one should you take? To me, maybe I should take my test because with my test I can still redo my code. But if I take my code only, maybe I cannot make changes to the code anymore without the test.
So that is something you can think about: if you are only left with a test, are you able to redo your code, or your project? Maybe if you think about it in that sense, you would sometimes be able to glean the sense that this test is good enough, has adequate coverage and then you can move on. Does that make sense?
Yeah, that’s actually incredibly insightful, thank you.
Any other questions from in here or with the app?
Cool. So Winston, I’m curious to hear then, coming from your experience working with Pivotal, you said that you wanted to move in and work with some smaller startups and take more of a full life cycle and broader approach to their engineering problems.
So how is that transition, what is so much different about working with startups and specifically how their engineering decisions are made and how their architecture tends to come together that you’ve found out about?
Startup engineering & architectural constraints.
Right. Well smaller startups definitely have a lot of constraints, especially resources are constrained. So firstly they might not have many engineers, secondly they might not have very solid tech engineers as well, to actually help develop the product in general. Of course, a lot of these smaller startups they don’t understand about agile in the first place. So what I do a lot of times, is firstly to help them understand what agile really means, and how we could use it to actually help them develop a minimum viable product.
Apply critical thinking in the development lifecycle.
Some clients will come to me and say, "hey I want to build this!" And tell me they have this big document that they have written across the span of six months to a year and they just want to develop their app, right?
So that’s not really agile, at all. I tell them this is not the way you would develop the app because as soon as you started writing that thick documentation, the thing is outdated as well. You do not know what you really need – unless you have really built it before. The market is ever changing, the environment is ever changing. So why are we so sure we should build according to this set of specifications that you have written?
The first step is to educate them that we need to be flexible and adaptable and play along to our environment as it changes.
We don't try and plan for everything from the very beginning but we also do a lot of re-planning in the process leading up to the development of the minimum viable product. That’s the first hurdle – to get the management to buy into the idea.
The second hurdle, then of course is to talk to their engineers about how they could develop the app in a maintainable and responsible manner.
So it’s about introducing them to the concepts of test-driven development or at least testing in general. Of course, after that you would bring in concepts like continuous integration, continuous deployment.
Pair programming isn't a blanket solution.
Depending on the projects, I don’t necessarily always introduce pair programming. Because honestly, pair programming requires you to hire for it. Not everyone is a suitable pair programmer. Pair programming requires you to have certain skill sets, for example: the ability to communicate well. The ability to communicate your ideas properly. And, obviously, to be a likeable person (laughs) so people wouldn’t mind sitting beside you for eight hours a day.
Not everyone can be a pair programmer, and of course if I go into a company which already has programmers, I won’t try and change it overnight. Like hey, "tomorrow, all of you will start doing pair programming!", because they weren’t hired to do pair programming in the first place and all of them won’t like it. But, at the same time, we understand what pair programming gives us and try to supplement it with other types of practices. The one practice I do a lot nowadays is actually code review, intensive and extensive code review.
So, introducing the concepts of:
let’s work on a feature
let’s push it out to a branch
let's push it to GitHub for a pull request and
then let’s get our peers to actually do a code review on them – before actually pushing the code in.
I think that fundamentally it’s important to make sure that everyone has an idea of how the code base is evolving and to just sort of like double check on each other’s work to make sure there’s no gross typo errors, logic errors that would result in the app failing itself, and of course testing. We teach them how to do testing properly and how to make sure the app is developed in a sustainable manner and maintainable manner.
This is some of the stuff that we speak to startups a lot of times, about. Especially in Singapore, a lot of startups are founded either by business people or by young, fresh graduates from universities. So either of them – the engineering experience to be able to formulate all of these properly will allow them to have a longer runway of sustainable engineering. That’s what the challenge is all about when running Jolly Good Code and talking to small and medium enterprises, and startups.
I was just going to ask for questions.
I see in the group chat here we have a question, it is: do you recommend that MVPs are validated before they’re built, for example by testing wire frames or testing the appetite for downloading the app via a test landing page?
Intend to solve a problem – before building a product.
Definitely. Fundamentally, when we want to build an MVP (Minimum Viable Product), the ultimate question that we need to ask is: what is the problem?
What is the problem that you’re trying to solve?
And at the same time then, what is your hypothesis of solving the problem?
I have seen clients who come to me who just want to build an app...where if you ask them about the problem they don’t really have a problem statement, but they just want to build an app.
It is for this kind of project that you would have a higher rate of failure, because it doesn’t exist for a need by itself. It just exists because I don’t know for whatever reasons, right?
I think ultimately, when you want to build something, you need to make sure that the problem statement is sound and you have a few hypotheses on how to solve it. Then, test the hypotheses first. For example, it could be wire frames or building a landing page. But I feel that at the same time if you can actually go out and talk to customers, potential customers, get their feedback on what you’re trying to do, I think that would be even more valuable. Because that’s when people tell you their actual pain points, and if what you’re trying to do will actually solve their pain points, or not.
Only when you have really, really delegated your idea – then, you go into building. Engineering is always an expensive task whether you’re doing it yourself, or you are getting somebody else to do it, right? It is not cheap at all so you don’t want to waste engineering hours trying to figure out what’s right or what’s wrong.
When you go into engineering you want to make sure you are at least 50 to 80 percent sure that this is what you’re trying to build because it would solve that problem that you had earlier. I think that is really, really important which is why you probably find a lot of lean principles coming in where people teach about how to do design thinking, how to actually go out to customers, get feedback, etc.
I think these are necessary skills and principles that you should know about, too – before you embark on actually building the application itself. Does that answer an idea?
Yes, cool. So what about the perspective of developers? If I’m specifically a junior developer, someone who’s - I guess we could start with someone who wants to step into one of these roles in a smaller company at a company that’s operating on more of a hair-on-fire type of theory of management...
Career "survival skills" for new developers.
What do you recommend, or what should they watch out for, in terms of making that jump from recently educated to butt-in-seat and working for one of these companies?
1. Feed your hunger to learn.
Right. Let’s talk about on a personal level first. So on a personal level, I think as engineers we must always be hungry to learn, to learn everything that we can – be it on the job or be it through online resources.
For example, to bring up another story that I had, how I transitioned from being a developer at IBM to becoming an engineer in a startup world. The story goes like this: when I started to look for jobs in the programming role, actually there were small, digital agencies in Singapore that were doing PHP, some hiring for junior programmers as well.
I was actually rejected by a number of them because they were like, "You are in a big company. You didn’t learn any valuable skills at all, actually. I know what you guys do over there. You are locked into a silo function and that’s what you do so I don’t think I can hire you, etc."
That really got me thinking and I decided that since my job isn’t going to give me what I can learn to progress over the next career goal that I have, I have to do it on my own.
Again a little bit of history, at that time there was this thing called Google Reader. It was an RSS reader by Google, it has now been killed by Google already. But I did a greasemonkey script that meshed up Google Reader and a Gmail account so you could actually have one interface with the Gmail inbox and Google Reader at the bottom. Also a bunch of other greasemonkey scripts and some of them were actually featured on LifeHacker.com.
With these site projects, I felt more comfortable with myself because I had been learning, I knew a little bit more about what programming’s about and then I decided to go look for jobs in other startups. They saw potential in these site projects that I was working on so that’s why they did hire me. So on a personal level it’s important to maintain that hunger to learn.
2. Practice humility.
Then, at the same time, I think as junior developers we have to have humility. The humility to learn from other people as well and to be able to accept opinions from other more, senior developers. Even if you’re stepping into these fresh startups, you might have come out of the code school with a set of principles that the code school has given you.
You have practices, but at the same time when working in reality, startups might work in different ways. They might have different opinions, different culture of how they want to get things done. So it would be good to have a sight of humility and learn from whatever they are doing. I don’t mean to say they could be right, they could be wrong! But to learn (laughs) what they are doing and to tell yourself whether it’s right or wrong – and make an opinion for yourself, after that.
3. Become an effective communicator.
I also think that it’s important for engineers to actually learn the skills of communication. I have seen a lot of engineers who cannot communicate well and even though they could write excellent code but they can’t really articulate what the code is about, so that doesn’t really help in getting their point across on why a piece of code should be done.
4. Embrace simplicity.
At the same time I think it’s also good to embrace this principle of simplicity.
Whenever I am tasked with doing some engineering work – I will always ask myself – and this probably comes from the fact of me having done test-driven development for three years and more. Now I think it’s about six. So when you start doing test-driven development you will find that you’ll be asking yourself this question a lot of times and this question is: "what is the simplest thing that you can do next, right – to get this out of the door?"
When you do test-driven development, you’ll be writing up tests first and you’ll be thinking: "what is the simplest thing you can do to get the test to pass?" And the cycle goes on. So whether you are doing TDD or not, I think that is basically a question engineers should always ask, and not try to over-engineer from the beginning. Because, we have actual product owners. These product owners are not techie people themselves, you will find that they always have a set of ideas that doesn’t really match up to what you have in mind, as well.
5. Get iterative, immediate feedback.
The idea is always build something in the simplest possible sense and get feedback as soon as you can – before you actually try to over-engineer this thing. You spend five days or even two weeks working on it, show it to the product owner before the product owner comes and tells you, "actually, this is not what I had in mind. I wanted the text to be written in color" right? (Laughs) And then you have built this monster over two weeks.
That’s something that developers, even junior developers should learn about simplicity and getting feedback as soon as you can.
6. Apply practicality in the completion of projects.
At the same time, pragmatism. What does it take to get things out of the door? Versus trying to - again like I say, this ties into simplicity, as well – versus trying to over-engineer the problem and trying to build a monster solution of it.
7. Ship often.
Last but not least these are causes (behind getting) things done. I think it’s very important for developers to just get things done and get things shipped. This really helps to prove your capability and your ability.
I have seen engineers who prefer to be in the more "research mode" so they have always been trying to research and go for a more elegant solution, but it doesn’t really help them or even the company in the long run because they are always taking a little bit more...and because the solution they generate might not be the best if there is no frequent communication with the product owner.
These are some points of advice I would give to any engineers who start to come into the startup world and join any teams they will be joining in the future. I think these are a few important points that I think engineers should learn about.
Just to piggy back right away on that, how can they show that? If I have all of these things or at least many of those things, how do I convince a prospective startup employer that I can actually do these things or that I possess these qualities?
Do you have any tips for kind of getting on the radar with regards to that, in standing out?
All of these things might be a little bit hard to showcase before you actually get into the startup.
I think during the interview it would be important to show your eagerness to learn and your humility in learning from them.
I think if you have site projects it would be even good to showcase that your project is simple.
You’re not trying to over-engineer a difficult problem or you’re able to walk through how you generate the problem to the future employers and showcase that the thought process is actually simple and pragmatic and they are just trying to get things done.
You understand the trade-offs they are making, you understand there’s always a balance between these two and that you have in mind future features that could be built, but at the same time you’re just building the simplest process at first and you know how you can actually transition over to build the future features later – without sacrificing the simplicity that you have right now.
I think these are things you could probably communicate during the interview so people will understand about your thought process.
I think we’re getting towards the end here. I’d like to open things up again to questions, though. We’ve covered a lot of ground from big companies to consultancies, test-driven development to getting your foot in the door, to all sorts of different things – so I imagine there must be questions.
Anyone have anything that you wanted to pick up on?
You can ask me anything about programming, about agile, about test-driven development, code review, etc.
Yeah, I have one question.
If you have - you’re trying to build a product that has a client site and (inaudible) - do you create two different MVPs or can I create one MVP that will service both?
If I got your question correctly you’re asking, say you have a product that has a client side and an admin side, is that right?
Yeah, like a supplier / client side or admin.
Right, so typically in such an MVP I think the most common analogy I have come across is marketplace, because in the marketplace you have to deal with the buyers and the sellers. I guess it sort of ties into your question. So do you have two products or one product?
I would try and build one product first. Keep it simple like I mentioned. Because if you start to build two products again you would need to split resources between the two products, and then you have the deployed end separately, as well. You can’t do any code sharing.
So the thing is, would there even be code sharing in the first place? You don’t know - I don’t know as well. Which is why don’t we just keep it in the same place because if there is it is much easier to do that.
You see, we try not to over-engineer the problem in the very beginning. What could happen is maybe the buyer side, the seller side only requires a login right now, a simple page to actually put in the form and that’s it. If it’s only that feature for a beginning why do you want to spin it out into two separate apps? Unless of course you already have a big set of features that you know you want to build and you know that it’s a security concern between these two set of users, you really need to separate them on the application level, on the database level, on the firewall level, etc.
Then yeah, you might want to split it up into two apps. But otherwise if it’s a relatively simple app, even if there are two roles or even multiple roles that will access the system, I would tend to try and start it in just one single app first.
Okay great, thank you!
I think Vishal, did you have a question?
Yeah, it’s been awesome just listening to you so thank you! I’ve been learning a lot. By the way I have been to Singapore once and it’s a beautiful, beautiful country. I really love the people and the culture there.
WINSTON Thank you! (Laughs)
(Laughs) I’m originally from India but I live in the U.S. now. My question is in terms of constant learning, what kind of resources should - let’s make it with respect to Ruby and Ruby on Rails, what kind of resources, what kind of avenues should one look at? I believe maybe going to conferences or that sort of thing helps, and if it does, like in what way?
More resources to deepen learning.
Right. So one of the resources, if you are talking about offline then meetups definitely would help. Go to meetups, meet people. I hope meetups have good talks that would allow you to be exposed to new ideas as well.
Go to conferences because that’s where you get to see the actual people who are writing gems of things you use every day. You might even get to meet Matz, the creator of Ruby himself, you will probably meet DHH the creator of Rails. So it’s good to meet them, be inspired by them and of course, to network with other fellow developers. Find out what they are working on. In fact, Ruby itself can be used for so many kinds of applications. Those are the offline events that you can go to.
If you’re talking about online resources I think for example there is this newsletter RubyWeekly.com, I think it helps create a set of pretty interesting Ruby articles that you can follow.
Sometimes I look at Reddit/Ruby, some of the discussions there are pretty good, as well. There used to be Railscast but it’s no longer actively maintained but it still has a couple of gems in there that are pretty nice and awesome. So it would be good to use it sometimes. I know GoRails.com is trying to set up as a similar nature as well, so you can definitely check it out.
I also write my own newsletter, it’s called RubyAsia.com. Actually I try and feature developers from Asia and Southeast Asia who have written articles about Ruby as well.
Sometimes it might not be newsletters it might just be people writing blogs, so go subscribe to these blogs, as well. That’s really my recommendation.
Great. I think that takes us to our finale here and basically what I’d like to lead out with is Winston obviously, we have a diverse crew of people who are listening to this.
In general, we get a lot of folks obviously educating potential developers who are in this position looking to get into this.
If you’re looking back at yourself or putting yourself in their shoes, what’s your parting advice in terms of getting themselves through that door and having a great career in development?
What I would say is programming is hard. (Laughs) But I assume that all of you who are here, watching this, or are reading the transcript of this, would have some passion in programming.
So it’s important to keep that fire burning within yourself and to continue improving yourself. Reading, watching, learning from your peers, learning from mentors, if you can find them. To continue like I mentioned, your hunger to learn new things. You don’t have to restrict yourself to Ruby, as well. Go learn other programming languages, see what’s the good in them, what’s not so good in them and develop your own opinions about what makes good engineering. What is a good practice and process that you yourself would like to be in, or would like your team would eventually evolve into.
I think for example myself I still love Ruby. I do Ruby every day but I still looked at other program languages because I want to see what they are doing there that could be applicable to what we are doing here. So it’s always good to keep learning. At the same time keep the humility in yourself, right, and be simple, be pragmatic, communicate well with your team.
I think ultimately what I always share is you need to care about a lot of things. You need to care about your users, you need to care about your products. But you should also care about your team and you should also care about your code.
When we’re talking about your team it means helping your team succeed by being a better engineer, contributing to all the practices and processes that you have within the team and helping to make sure that these practices and processes are upheld, too.
You care about your code, you write tests and you help people understand your code easily so that it becomes maintainable.
I always have the principle of try not to "own" your code – in the sense of, let other people have a chance to read your code, understand it and make changes to it, as well. In this way, you will improve and be a better engineer because you would read about what other people are trying to do as well, what they are trying to change. Ultimately, I think if you practice all of this, it will lead you to become a better engineer in general.
Alright, thank you so much. If anyone here who is listening wants to get in touch with you what’s the best way to do so, just to say thank you?
Yeah, you can drop me an email - it’s Winston@JollyGoodCode.com or you can ping me on Twitter it’s @WinstonYW.
Alright, well thank you very much for joining us! Everyone who is listening thank you guys as well. Winston, much appreciated and I hope you all join us next time. Have a great night.