Throughout each day, our CTO, Ken, receives loads of questions about coding, web development, career advice, and tips for the job search. And so, earlier this year, the mailbag blog series was born.
For this one, we decided to switch things up and go live with Ken on Facebook for a special summer edition. I sat down with him for about 50 minutes, armed with a list of the best programming questions he received in June and July pulled directly from his inbox, and he dropped a ton of knowledge on me and the live audience– who got the opportunity to ask a few additional questions as well.
If you missed us then, you can still watch the video here. If you want to read up on what we talked about or are looking for a particular answer, keep reading! Each question includes the corresponding video time code.
Have a question that you would like to be featured in the next mailbag? Shoot an email to mailbag@thefirehoseproject.com. You may be able to increase the chance that we feature your question by throwing us a like on Facebook or a follow on Twitter.
(1:15) Can I be called a programmer if I know only one programming language?
–FM, Delaware.
This is a really good question and I like it a lot. The answer’s yes and no– that’s going to be the answer to a lot of the questions, because there’s usually a lot of shades of grey in between.
Can you consider yourself actually a programmer if you know one programming language? Technically, yeah. If you can write programs, you are a programmer. But you’re not a certain type of a programmer. There’s this concept of a polyglot programmer, which is the idea of somebody who can work with multiple different programming languages. Those are the developers that are actually a lot more in-demand, so knowing one programming language is good, and I don’t want to discourage you from starting, but I would highly encourage you to learn multiple programming languages and don’t just pick one and go with it.
The reason why is, all programming languages have different concepts and different ideas, and learning different languages that have different concepts will teach you how to think about all programming languages and different concepts in different ways.
You really level up as a programmer when you learn multiple ones. Don’t let that discourage you– start with one, but eventually you want to pick up more programming languages to expand your horizons.
TLDR: Start with one, but definitely try to learn more as you go.
(2:47) If you could never write code again, what would you be doing instead?
–SK, Australia.
This is such a hard question. Trying to think about what is actually behind the question– the mentality of if I was fired from my programming job and was never going to be able to get a job as a developer again, like if Boston blacklists me and I just can’t get a job as a dev, what would I do then?
I would still program, probably on the weekends, because I just genuinely enjoy learning about technology and doing things like that. But I’m going to take the question as, “what would my career be?” as opposed to doing programming. And I think I would probably just continue to do the same type of things that I’m doing right now, so I’d write blog posts, I would talk to people, I would just continue to do the type of stuff that I do now that just isn’t programming-related.
(4:00) Should I make a portfolio site?
–YY, Saint Paul, MN.
I get this question a lot. People overplay the value of a portfolio site. Portfolio sites are good because they allow you to showcase what you are: you’re a web developer, and you’re actually saying that from the center. But people are going to care more about your code than your portfolio site itself.
My suggestion is to spend less energy building out a portfolio site, and spend more energy making your code on GitHub look exactly like it should. As a hiring manager, the steps that I take to actually determine if somebody is a good developer or not isn’t looking at their portfolio site. It’s going on GitHub, looking at all the code, looking at various commits that they’ve done.
Making sure that your GitHub is in good, working order is actually– in my opinion– far more important than having a flashy portfolio page that looks really neat.
How can you optimize your GitHub? It’s actually pretty easy to do. You want to think about what items are most impressive on your GitHub, and keep those, but remove everything else. An employer isn’t going to look through every single one of your GitHub repos– they’re not going to look through your entire GitHub account. Instead, they’re going to look at one or two things, so you want to push them to look at the thing you think is most impressive, or most representative of what you have.
My advice is to take down a lot of the beginner-type stuff, the stuff that you do as you’re starting out. Remove that stuff from GitHub, leave the stuff you’re working on that’s a little bit more advanced, and feature that more prominently. Portfolio pages are a bit more important if you’re looking for a front-end developer job– so if you’re looking for a back-end developer job, I’d say it doesn’t really matter that much at all. Front-end, it starts to matter a little bit more, but still, as a developer, you’re being paid to write code, so you want to be able to spend most of your energy when it comes to showcasing the code that you wrote, as opposed to spending time designing things, designing your portfolio, making it perfect, because at the end of the day, somebody isn’t going to pay you to do design unless you’re a designer.
Don’t worry about the portfolio page too much. Maybe have something that works, but don’t go crazy overboard.
The last tip that I might add is you can go to a website like themeforest.net, and you can buy themes for like $8, which is just HTML/CSS that’s pre-made, it looks really good, and then you don’t have to spend any effort on building the actual portfolio page yourself. You take a pre-made one that’s basically done, fill in the blanks, and then you have a beautiful portfolio page that probably looks a lot better than anything that you would do on your own, because people are spending a lot of time and energy designing them.
TLDR: Focus on GitHub first. If you want to have a portfolio page, it’s not going to hurt you, but as an employer, I’m looking on GitHub. I’m not really going to be spending too much time on a portfolio page.
(7:30) What is a key piece of advice you have for someone who wants to be a valuable asset to a company?
–JZ, Chicago, IL.
This applies to any type of job or career or path you could take. My advice would be to focus on responsibilities versus tasks. If you think about the role that you do, you’re being paid to write code. But instead of thinking, “I am being paid to write code” and the number of lines of code is how successful or how meaningful the impact you’re making is, I would think about whether there are certain aspects of the site that you can take full responsibility for, and just absolutely own.
Think about taking bigger tasks and the bigger tickets, as opposed to just knocking out a lot of small ones. Try to find areas that are bigger and be able to contribute in those areas as opposed to doing just a couple of small things, one after another after another.
Think about what areas of the product you want to be the expert in, then do the work around that and just really own that level of it. Think about it in terms of responsibilities versus tasks, and don’t count the lines of code or do anything like that. You want to just be adding value and be the expert at a certain niche area, even if it’s something really small. Own user login, own the payment aspect of it. If you become the expert in one narrow field, people will come to your desk and you will become a lot more valuable.
(9:32) Financially speaking, which computer languages can earn the most for the programmer?
–RK, New York.
I really don’t like this question at all. It’s a question that gets asked quite a bit, but I think it comes from the wrong place. If you’re trying to optimize for dollars and switch careers, in my opinion, it’s not the right attitude to have. I think you should think about it in terms of what will make you happiest, and then do that.
If you’re thinking about what programming language you should learn as a beginner, don’t think about it in terms of what is paid the most. At the end of the day, if you’re a programmer that learns multiple programming languages– if you’re a polyglot programmer– you’ll have the ability to pick up new programming languages pretty quickly too. Being an expert in one particular programming languages because it’s the most financially viable– it’s just not the right opinion to take. Instead, you should focus on which one has a better community, think about which one makes you feel more invited, which one is a programming language that allows you to build applications faster. And then I would suggest that you choose that one.
In my opinion, I think Ruby is really just an excellent programming language; the community there is really wonderful. There might be programming languages where you can get a slightly higher dollar amount, but if you’re optimizing for what actually counts, I would think about the community, go to some meetups, see the type of people you’re meeting there.
(11:20) I was on a technical interview and was asked FizzBuzz. After solving it (correctly) the hiring manager asked if I could solve it in a different way. How should I have responded?
–RR, Atlanta, GA.
On a technical interview, they’re going to ask you technical programming questions, and when it comes to technical things, there are usually tradeoffs in different approaches. FizzBuzz is pretty straightforward, so I would probably feel pretty comfortable solving it the normal way and defending the fact that I solved the problem, and solved it in the generally accepted way.
For other types of questions, I would just talk about the tradeoffs. Sometimes one way can be more efficient, but less human-readable. Other times, things can be slower, but maybe it optimizes for memory. There are always going to be tradeoffs between some approaches and other approaches, and the correct way to deal with those types of programming questions is just to talk about the tradeoffs, and then ask, “what tradeoff are you trying to fix?” Then work towards refactoring it with that particular thing in mind. Really understand where they’re coming from, what they’re trying to get you to do, what tradeoff they’re finding that’s not optimal, and then go and take it in the opposite direction. Make sure that they push you in the right direction.
(12:56) How long should my resume be?
–CM, London.
It should be one page. I always suggest that you have a single-page resume, and the reason being is, if there’s a stack of fifty resumes, and you’re going through all of them, you’re just not going to go to the second page of anybody’s.
The answer is just one page. Don’t ever go onto the second page.
(13:21) I want to do a side project but I don’t have any ideas.
–KP, Boston, MA.
I think one of the best ways you can get ideas is by looking at problems that you have in your real life, and think about how you can build technology to facilitate solutions to actual problems you have. If you can actually do that, what you’ll find is that you’ll be motivated to actually work on it, and you’ll have a reason to keep putting in the time and energy and effort into it, so that’s the number one way that I suggest coming up with an idea. Find something that you actually will genuinely use, and then build that.
But, maybe you can’t think of anything like that, and that happens sometimes too. From there, come up with some silly ideas. An example of a random idea that I have is, I think it would be fun to build out a web application that lists out characters from It’s Always Sunny in Philadelphia. I just really like that show, I think it would give me an excuse to watch the show again so I could fill up my database of characters with the different characters in the show, and it’s just kind of a silly thing that would bring value to my life. Focus on coming up with something that actually brings value.
(14:58) I just started learning to code, and at times, I feel like I’m simply not smart enough to understand concepts right away. How do I prevent getting stuck and what’s the best way to keep learning and moving through material?
–TS, San Francisco, CA.
Basically, it comes down to the imposter syndrome. What the imposter syndrome is is this feeling of inadequacy and that you’re maybe not good enough to do something. Whenever you’re learning a complex topic, like programming, the imposter syndrome is going to come up.
My advice is to power through it, ask for help, find people who have been in your shoes and can relate to you. I’ve been in so many situations where I’ve felt the same thing– the imposter syndrome. I remember my first job as a developer, I kind of felt like I tricked my way through the interview and I got a job. In retrospect, I think they knew exactly what they were getting, but it can be really easy to underestimate the value that you’re bringing.
Focus on building the confidence that you’re a great developer, talk to other people who are going through the same thing. Try not to get stuck, and if you do get stuck, ask for help or figure out a way to get unstuck, and just accept that you’re not going to know everything. There’s just so much, technology is changing so, so fast that you can’t master everything. You’re going to not understand something. The sooner that you just accept that that’s the way the world is going to work, the easier your life is going to be.
TLDR: Make sure to reach out and talk to people, talk about your feelings about that stuff, and don’t stay stuck too long.
(16:58) Do you have any performance hacks you’re particularly proud of?
–AM, New York.
The performance hacks that I have, I’ve written blog posts about, so I’m gonna push you guys to check those out. One of the performance hacks that we have is this ten-tab rule, the idea that if you don’t know something, do a Google search and click on the first ten tabs. We wrote a blog post on that and how that can solve most of your problems. That’s a performance hack that I think is particularly interesting.
There are other performance hacks that you can see on our blog– check out our blog and you’ll get some ideas.
(17:45) Is Java substantially as fast as C?
–MD, San Francisco, CA.
Thinking about performance makes you think about how programming languages are built, how fast they run, and what infrastructure they run on top of. The fastest programming language by far is assembly language. But it’s really, really, really difficult to program in assembly language because you have to think about a lot of things.
C is on top of assembly language, and it’s actually physically capable of being able to write pretty complex programs without being really confusing and super abstract. I would say that C is probably more performant than any other language that you can actually write programs in. Java is almost as fast as C, it’s actually quite a bit slower, but when you compare it to other programming languages, like Ruby or Python or JavaScript, it’s just a lot faster. And then you have those other languages which aren’t as performant, but are just so much easier to write.
That’s really what you’re getting– you’re saving your time as a developer writing code, as opposed to saving time as a developer executing the code because most of the time, the bottleneck is not going to be the execution speed of the program, it’s going to be your time as a developer and the number of hours that you spend doing it. Despite the fact that it’s not the most performant programming language, Ruby and Python and JavaScript are all really excellent programming languages that will help you build things really fast, as opposed to having the programs be super fast. At the end of the day, they’re fast enough. There’s no need to be absolutely, ridiculously performant in all of situations.
(20:31) How should one get into the Ruby on Rails market after having worked for 10+ years developing with other languages? Is it feasible to get remote work based on this situation?
–Ale, from the audience.
If you’ve been programming in other programming languages, I would feel pretty confident applying for jobs even without knowing Ruby on Rails at all. At one of the last companies that I worked for– WHERE.com– we ended up hiring a developer who had zero ruby programming experience and was very open about it. In the interview, he did all of his whiteboarding stuff in the programming language Scheme, and he did a great job. He ended up picking it up super fast and being one of the most effective developers on that team.
I would suggest just applying right away for the positions, and if you have 10+ years experience programming in other languages, I wouldn’t sweat the details. If you want to learn it, go ahead and spend some time programming in it, but you’re probably capable of starting to apply for normal jobs, like mid-level, senior jobs. Probably senior-level jobs if you’ve been doing it for 10+ years.
For junior people, I would suggest not looking into as much remote work, but if you’re somebody with a lot more senior experience, I think you’d be in great shape to just go ahead and start applying for those jobs. I think you’ll be surprised about how welcoming the Ruby community is to other programming languages.
(22:09) Can you share some pro-tips on how to make an app look good quickly?
–YY, Saint Paul, MN.
The first thing you can check out: Twitter Bootstrap is probably one of the easiest technologies to make things look pretty solid to begin with. If you want to make an app look really polished and have all the design elements perfect, color becomes kind of an important thing. Understanding color theory is something that designers spend a lot of time talking about, and they spend a lot of time thinking about typography and things like that. As a developer, I don’t have the background on what is the best font and the theory behind how all of these things work. I don’t have the theory about the color combinations and things of that nature.
Having said that, Google has released this thing called the Material Design. You’ll find the amazing color choices that you can pair together, along with other types of ideas. They basically tell you, if you use these types of design elements, it will look good. This is the science behind it. As opposed to having to learn complex theory about hue and saturation and things like that that designers need to know. But as a developer, you can just cheat and use the Google Material Design colors, and you can get a really well-polished application pretty quickly.
(23:49) Is it basically pointless to try to learn to code in your late 30s?
–PP, Canada.
This question kind of presumes the answer is going to be “yes.” It has some negativity associated with it. I would say that if you have that type of an attitude of, “is it pointless for me to even try?” you’re probably not going to put the effort in to actually succeed.
If you’re in your 30’s and you want to become a web developer, it is absolutely practical, and you can actually do that. But I would focus on having a positive outlook, positive expectations, and really put the work in. If you’re doing anything that’s going to take a lot of work, and you have the mentality that “this is probably going to fail,” you’re probably right.
I would focus on shifting your mentality from being, “why am I going to fail?” to be, “how am I going to succeed?” Ask yourself a different question, and regardless of the question, you’ll be able to find the right answer.
TLDR: Yes, you can learn how to program in your 30’s, you can switch careers– I’ve seen tons of people do it– but make sure that you’re doing it the right way.
(25:10) I’m having a hard time memorizing stuff. What are your pointers for memorizing things faster?
–TS, San Francisco, CA.
Memorizing stuff is super overrated. I would focus not on memorizing stuff. We actually wrote a guest blog post recently on Learn to Code With Me. If you go to that site, you can see a post that I wrote about how school has trained us to learn things ineffectively.
The gist of it is that school taught us it’s important to memorize a bunch of facts and be able to come up with the answer on the spot without being able to reference any other materials. When it comes to programming, cheating is highly recommended. Instead of learning all of the things and memorizing things, learn where to look to cheat.
Instead of spending your energy memorizing stuff, spend your energy thinking bigger picture, and if you have the bigger picture, you’ll have a much easier time of memorizing things because you’ll just keep looking it up, and eventually you’ll get sick and tired of looking at the same place, because you’ve looked there so many times. After the tenth time you look in the same GitHub repo at the same line of code to see how you did something, you’ll realize, “if I just commit this to memory, it will save me time down the line.”
TLDR: Don’t worry about memorizing stuff, it’s super overrated. Instead, think about bigger picture concepts, and learn where you need to look when you need the right answer.
(26:43) What are some good ways for an engineer to measure their own productivity?
–DD, North Carolina.
Measuring your own productivity is really difficult. I would probably suggest just not doing it at all, and I would suggest asking people around you. If you’re on a dev team with many other people, talk to other devs. You could literally ask people, “how do I stack up against the other people in this company?” “Would you say I’m the top performer?” “Would you say I’m a bottom performer?” When you ask for feedback, a lot of times you get answers that you wouldn’t necessarily expect, and those are the things that really will push you to be a better developer. Ask for feedback, ask for criticism, and support people telling you the truth.
Don’t shut people down– if somebody gives you feedback that, maybe you do a really bad job at a certain type of development, maybe you’re really good at the back-end side of things but whenever you need to do something in the front-end, you really struggle– people can tell you that kind of stuff, and then you can decide if you want to spend less time working on the stuff that you’re struggling at, or if you want to do something else.
(28:05) With so many people wanting to be a programmer, what are some reasons that I should not be a programmer?
–CS, Colorado.
The reason I think is the worst to get into this industry is because of the dollar amounts. If you’re getting into programming exclusively because you want to be well-paid– because software engineers are really well-paid– if that’s your only motivation and the idea of building something creative, working on a dynamic team with other people, having a culture you love, and building a product– if these types of things aren’t important to you and you’re literally optimizing for the one variable of making the most money humanly possible, I think that is a bad mentality.
There’s more and more people moving in that direction. Coding is becoming cooler and cooler, and you get status if you’re working at a company like Facebook, or Google, and sometimes the type of people that would be attracted to the financial industry– companies like Goldman Sachs, things of that nature– are now moving their sights to a more tech-focused thing. If the only motivating factor is making more money and having a “cool” job, building a “cool” product– if that stuff doesn’t sound interesting to you, I would suggest avoiding the tech industry. Not necessarily because you won’t be able to succeed, but because you’ll be getting into it for the wrong reasons.
(29:44) How do companies scale apps to be able to be worked on by dozens or even hundreds of developers?
–ES, Massachusetts.
This is such a good question because in the real world, applications get really complex really fast, especially as more people are working on them. As you’re learning to code by yourself and you’re working on projects by yourself, you’re the only one making improvements and changes, and you know 100% of what’s going on. As soon as you get more people, a full team of developers, something like 6 or 8 working on the same project, that project starts making momentum really fast. All of a sudden, if you’re working with other companies and other teams, you need to build even more projects and the complexity just scales really, really quickly.
In order to deal with these types of things, there’s a couple of solutions that people have taken. One is the idea of using a concept called microservices. It’s basically shoehorning out a very small sliver of the app, and building an entire app around one small component of it. An example of a microservice could be user login. You could have a single app whose sole purpose is just to deal with user login, and it doesn’t do anything else. It doesn’t deal with user-generated content, it doesn’t deal with anything else except user login. When you start narrowing these bands in these microservices that have really small functionality, all of a sudden, you don’t need to worry about massively complex things.
Another approach that people generally take is to split the application into two separate sides that have two separate applications. One could be a front end that has JavaScript and CSS and things of that nature, and also a back end. The back end might not have any visual components, but it’s doing things like talking to databases, interacting with those things. By splitting those things apart, you can change the display and the functionality of a webpage really quickly without having to worry about the details on the back end.
(32:00) How should I follow up with a company if I haven’t heard from them in a while?
–MF, New York.
First, if you’re applying for a job, you want to make sure to follow the best chance that you have to get the job. After the interview, you always want to send a thank you– just “thank you for meeting with me”– especially if you can get the manager of the dev team or somebody involved in the hiring decision, as opposed to some technical recruiter that probably won’t pass your message along to the people making the decision. Be responsible and polite, and think through the process. One example is thanking people, but then the question is actually about how to follow up.
Following up is actually really important because it shows that you’re on the ball. You don’t need to think it through too much, but just actually sending a message a week or two after saying:
Hey (contact name),
I really enjoyed when we met in person. I’m still interviewing at a few other places– I was curious what the status is of the job that I’m interviewing for.
A one- or two-paragraph email that just quickly checks in and basically just asks the question. They’ll probably just give you the answer to the question, which is “what is the state of this particular thing?” Either they’ve decided to go with somebody else and they decided that they weren’t going to tell you because they just didn’t care. Maybe they’re still making the decision and there’s other interviews in process, and they still don’t know what the right decision is. But you just want to know the answer to that, so you don’t just wait for something when the decision has already been made and you just haven’t been updated.
TLDR: Always follow up, and make sure to send thank you emails. It doesn’t hurt to be polite.
(33:49) The book Cracking the Technical Interview covers a lot of stuff. Should I know all of it?
–JM, Washington.
I love that book. Cracking the Technical Interview is a book by Gayle Laakmann McDowell. She’s also on Quora, and she answers a lot of questions about the technical interview process and I suggest following her there, too, because she has just so much good insight about how the technical interview process works.
The technical interview process is kind of broken. Because of this, you need to know exactly what the steps are going into it, and the book Cracking the Technical Interview kind of outlines the worst case scenario. If you’re going into a situation and you’re prepared for the worst case, and something that is a lot less painful happens, you’re going to knock it out of the park. My advice is to look at the book Cracking the Technical Interview, don’t be too intimidated by it– it’s going to be covering programming questions in the languages Java and C. The same type of questions will apply, but you won’t necessarily get the answers to the questions in the book itself.
It’s an excellent book, and I highly suggest checking it out, especially if you’ve just graduated a coding bootcamp or done a solid amount of self-studying. Or even if you’ve graduated with a CS degree, and you want to know what the worst case scenario is. But don’t look at it as: “this is going to be in 100% of the interviews.” This is just going to be the worst that could happen, and if you prepare for the worst, and you don’t get the most complex technical interview, you’ll just knock it out of the park and do a lot better.
TLDR: I really suggest checking out the book, but don’t freak out if you feel like it’s a little bit too advanced.
(35:42) Should I publish my not-so-well-written but working web app now, or rewrite it and publish in a few months?
–HW, Pennsylvania.
It depends. It depends on why you’re building a web application to begin with. If you’re building a web application because you want to launch a product and you want to experiment with users, and you want to get user feedback and maybe launch an idea, you should launch as soon as physically possible. You should launch with a landing page, start getting users that way, and then build it up as quickly as possible, starting as soon as possible. You want to launch as fast as you can, and get the feedback that you need to actually make different decisions. That’s my advice if you’re building a product to build a business.
On the flip side, if you’re looking to build a web application to impress a potential employer, a quickly-hacked-together landing page and prototype isn’t going to necessarily help you get a job. I would encourage you to do it with the better practices, maybe writing tests first, using test-driven development– if you’re just looking to get user feedback, maybe TDD isn’t terribly important for you. Basically, understand what the reason behind it is, and once you understand the reason why, then do what makes the most sense for you.
TLDR: If you’re building an idea because you want to prove it out and build a business, or just potentially get users on the product, ship it as soon as possible. If you’re looking to build something that’s going to showcase why you’re an awesome developer for employers to look at, focus on the details that matter: test-driven development, using best practices, even though it might slow you down a little bit.
(37:36) What are the best practices for getting a reference?
–DH, Illinois.
This is a really, really good question. For context, if an employer is going to be asking you for a reference, they’ve likely already mostly made up their mind. They’re not going to be spending their time reference checking if they’re not pretty sure that they’re going to hire you. So, if somebody asks you for a reference, give yourself a pat on the back and know that up to this point in time, you’ve done a terrific job. But the worst thing you could do is ruin this shoe-in opportunity to knock it out of the park by just quickly giving them somebody without giving your reference feedback about what is going to be happening.
Always check with the person you’re giving the reference to that it’s okay with them, and they’re willing to give a reference for you. It’s so much better if they say to your face, “I don’t feel comfortable acting as a reference for you.” That’s so much better than them saying that to the employer. If the employer sends them an email saying, “will you be a reference for [whoever],” and the person says, “no, I don’t feel comfortable with that,” you’ve just immediately put yourself at a disadvantage when sending one email could’ve had somebody say to your face, “I don’t really feel comfortable and I think you could probably find a better reference than me.” It doesn’t happen that often, but given the fact that you can pretty much knock it out of the park and it only takes one email, you’re crazy if you don’t send it.
TLDR: Always check with the reference before you send the intro to them or give their email out.
(39:23) What are your thoughts on Turbolinks?
–CB, New York.
I really hate Turbolinks. Turbolinks is a kinda neat package that the creator of Rails did that allows your apps to be really fast. It kind of magically behind the scenes makes it so if you click a page, it will do some fancy magic that makes the page seem to immediately snap and go to the next thing. The magic behind the scenes– in my opinion– is just too much. It can get in your way pretty easily.
That’s my opinion on Turbolinks 2, I know Rails 5 just came out and there’s Turbolinks 5 now, and I don’t have too much experience with the new version of Turbolinks, so I’m sort of bashing the old way. I don’t necessarily know if the new way is better– I think it probably is a lot better, but I think, ultimately, I prefer to use Ruby on Rails apps without it. But, it’s cool that you have the option if you want to use it.
(40:38) Do companies pay for employees to continue their education?
–CO, California.
It’s going to depend on the company. The easiest companies to get to help you improve your education as you’re working for them is working for universities. Universities have a lot of tech jobs, believe it or not, and jobs in the programming field, and they have it set up– usually– so you can take courses at their college for cheap, or free, or really affordably. Basically, if you work for a place like Harvard, you can potentially go to Harvard classes, get some of a Harvard education without having to pay a whole lot of money. That’s option number one that you have, which is going the academic route, which I think is a solid move if that’s your plan and you want to get a Masters in Computer Science or something like that.
You also could go to a bigger-type company– Fortune 500-type companies, like the Microsofts, and the PayPals, and the eBays. They’ve spent time to figure out what the compensation package should actually be, and how to incentivize people to stay at those types of companies. Often times that includes a certain amount of money each year to take certain types of education. Sometimes you can use it for only the types of education that are like a university degree, other times they’ll let you use it for other types of things too– things like our course, things like Udemy, Team Treehouse, things of that nature, too. Different companies have different policies in place. Universities have the best setup, where you can just potentially go to that university and take classes there. Alternatively, big companies are going to have structures in place, smaller type companies– companies with less than 100 or so people– probably haven’t taken the time to figure that out, because it’s not something that they need because they don’t have a crazy scale of employees where they really need to optimize their compensation package with other types of perks like education, bonuses, and things like that.
TLDR: If you want to continue your education, look at the different companies and always ask about that in the offer letter. Sometimes there will be stuff in the offer letter that you just don’t know about. A lot of people at the previous companies I worked for didn’t even fully understand all of the opportunities that they had, and it’s just kind of sad that you have the opportunity to do this in a lot of cases, and you just don’t know. Always ask when you get the offer letter to see if that’s actually an option, and what the terms and conditions are.
(43:21) How do you set up Trello to organize topics when working on a team?
–RR, Atlanta, GA.
Trello is an amazing organization tool that I absolutely love. Its UI is pretty solid, and it is pretty good for organizing certain types of things, particularly when organizing things like building tasks or working on a project, especially on a team project where there’s multiple people. I suggest breaking it up into different boards of the state of the feature that you’re working on. In general, you’ll set it up where there’s a backlog board, which is kind of the ideas that maybe eventually you’ll work on. You have a board for “currently in progress,” you have a board for “shipped,” and you have a board for “QA’d.” You have different boards, and you can drag a task along as the status of it changes.
Basically, my thought process is: think about the process that your team is building features on– how are you organizing things, how are you doing your sprint planning, are there concrete stages of the actual task at hand? Then, think about what happens when things move from one state to the other. How can that happen, and how can you use Trello to keep track of what state an actual feature is in.
I think Trello is a wonderful product. I really suggest using it, especially if you’re doing some development stuff, and I suggest thinking about breaking features up into small components, and shipping early and often.
(45:08) When working with Ruby on Rails environments, would you really recommend using a test environment, or, once the project is ready (and really tested), would you directly move it into production?
–Ale, from the audience.
This a pretty complex, specific question and it’s going to depend on the actual situation at hand, and the impact that failing will have. If you look at companies like Google, for example, Google launched their Google Plus app. When they did, they needed to support such a scale of users– on day one when they launched, they needed to support hundreds of thousands, if not millions, of users, and be supported for that situation. In situations like that, you really want to make sure to test it in all ways humanly possible. You want to first have it tested on localhost, then you want to have a separate environment– maybe a separate staging environment– that people can run tests on for more experimental stuff, and then you’ll have a production site, which should be really well-tested, and then you can launch once all of those three things are up and running.
For smaller projects, if you’re not going to have to deal with hundreds of thousands or millions of users on day number one, do what you think is right for you. If you think that having multiple environments at early in the stage as you’re building up this stuff is only adding complexity and not adding any benefit for you, do what you think is right. Eventually you’ll need to test it in production, but ultimately it doesn’t really matter, and you’re probably the only one that’s going to be impacted. It depends on your workflow, what you think the right answer is, and if you’re working on a team of other developers, that’s going to matter, too. The more that the downside of something going wrong becomes a bigger and bigger thing, you need to play it safer and safer and safer.
Ask yourself, “what is the worst that can happen if bad stuff happens?” and if that is really just a couple of people see an error message, maybe it’s not the end of the world. It might not really matter, but ultimately, the best answer is, in most situations, do what works for you, do what works for your team, and communicate with everybody involved in the process about the pros and cons. There’s tradeoffs of setting things up in different ways, and if you do it religiously just because of one of the arbitrary decisions that somebody made without talking about the pros and cons and the tradeoffs and talking about all of the complexity, you can easily make the wrong decision.
TLDR: Think about the pros and cons, think about what works for your team, and do what works for that. (Unless you’re in a situation where failure is just unacceptable. If that’s the case, then you need to play it very, very safe.)
(48:37) How can I determine if a startup is legitimate for a position?
–RR, Atlanta, GA.
There’s nothing preventing me from just going on AngelList, creating a page for a new company, and having a new “startup.”
There’s a couple of questions that you can just make sure that a company is actually legit, and they’re probably going to pay you, and it’s going to be a position that’s going to help further your career.
One question is, “how many employees do you have?” Companies that have employees are generally pretty legitimate. If the answer is, they have 5, 10, 20, 60 employees, yeah, that’s a super legitimate company. They’re likely to pay you, they’re probably going to pay you competitively. If the answer is 1 or 2, you probably want to start auditing some of the business questions. Are they going to be able to afford to pay you next month? All of a sudden, thinking about the business’s financials becomes a lot more important. Questions that you could ask are: “Have you raised venture capital, and do you plan to?” “What is your run rate?” “What is your burn rate?” Know the financials of the company to know that you don’t have to worry about getting a paycheck.
What you don’t want to have happen is you work for a company for a month, and they just can’t pay you. That’s what you want to avoid, and you can do so by just asking business-related questions.