Fireside chat with devs

This is my blog entry for the course I’m taking at OneMonth called Programming for Non-Programmers. I’m a product manager at an employer branding research company in Sweden and I work with enterprise software on a daily basis. I like to learn new things all the time and that’s the reason why I joined this course.

As part of the home assignment for the course, I’ve interviewed two developers (Alex and Kim). Both of them have more than 5 years of professional experience and they started coding when they were in school. Alex is primarily focused on mobile development and Kim on web development. In addition, I discovered that they both know many other programming languages outside of their every-day work scope. The questions I’ve asked them may differ, however, most of them are similar.

1. How did you learn to code?

Kim: I taught myself what code looks like when I was young. I wanted to make game cheats, so I searched for cheats on the internet that I could copy, and then I changed them. This is my first time programming.

I would later improve on this by making more projects that I did not know how to make from the start. I read forums, ask people in chat rooms, try to read code written by others, etc. When I joined university I think I could already code well enough for a junior developer position.

Alex: I started coding in school because a computer was an awesome black box for me. And then I got my first job as a mobile developer. You can get strong skills by only developing real products.

You should code things (apps, services, etc.) which will be interesting for you, no matter what exactly it will be.

2. What do you like about coding?

Kim: Many things, but on the top of my head I like that:

- Programming can be used in many different areas and solve many problems, and to work in an area you as a programmer must learn it. If I am to write a poker program, I must first learn poker!

- Programming is science and art at the same time. You can look at a large and complex problem and think “wow, I will never understand all of this”, so instead of solving the big problem you break it down into many small problems and solve each small one individually. If you solve the small problems in such a way that they can be put together, then people will put them together to solve the very big problem, even though nobody still understands how to solve the big problem from the beginning!

- Programming is storytelling for people, not computers. Your computer will run any shit you throw at it, but a person will be sad if you throw at them shit. When you write a code you write it for the next person that will read it, which could be a colleague or even yourself in the future. You must try to write your program so that it is easy to understand because the code is read many more times than it is written. It must tell a comprehensible story.

2. What advice would you have for someone learning to code for the first time?

Kim: Take your time to read code that you did not write, and try to understand what it does. Don’t ever be afraid of opening something up and see how it works on the inside.

Alex: Theoretically speaking, it is not a big deal to learn how to code. The main difficulty in development nowadays is a big amount of additional tools and libraries. In my opinion, understanding a technology stack is more important that actual programming. To understand it, one can ask a team lead or an engineer to draw a scheme of how a product works without specific details. Then you can dig deeper once you understand the big picture.

As an example, let’s look at Facebook. There is front-end (the part that is in your browser) and back-end (the part that transfers info to the browser). The back-end consists of a few apps which are located on the servers. And, there is a business logic on PHP. Data is stored in MySQL. To make PHP work faster, we use HHVM. Again, consider my explanation as an example.

3. What matters to you when you choose a project to work on (work or side project)?

Kim: The biggest factor is that the project needs to solve a real problem for a real person. I don’t like to program just for the sake of programming. It’s also very important that I have the freedom to make things a little bit better every time. It’s OK if the code is bad, as long as I have room to improve it. If I can involve some exciting piece of technology that I might not have worked with before it is also a big bonus.

Alex: To me there are two most important factors: challenge and usefulness. Usefulness is based on my internal convictions. I’d love to work on an educational project for kids, but to develop a new social network would make me think. There is no formula, it all depends on the project.

4. How do you filter people that you’d like to work with? Is there any selection criteria?

Kim: I radiate towards social people that have good communication. It is very important to communicate what you are thinking and feeling because so many programming decisions are based on gut feeling and instinct. I also radiate towards people with opinions. I find it very frustrating when somebody don’t care about the code or the quality as much as I do. It’s nice if they have different opinions, as long as they care about it.

Alex: It is difficult to filter people. I usually work with people that I met/worked before. As a team lead, I always insist on a probation period. I don’t really care much about a test assignment but rather how it feels to work with this person. I don’t really share this one-sided HR approach meaning that we look for someone who would fit perfectly. It also matters how we match with his/her expectations. And this is only a matter of real work practice.

5. How can a product manager earn your trust? What do you think he/she should know?

Kim: I think communication is very important. A product manager is a gatekeeper between stakeholders/clients/management and development/design. You must be able to say No to both sides, to keep the balance. Talking, every day, code or product or how development feels I think is important. Development department will trust you to have a good overview.

From developers’ point of view, you are the client. You explain what problem exists, and what it is to you. You must try not to explain how to solve your problem, you need to trust your developers and designers to make good solutions. Trust is always two-way!

6. You can program in many different languages. How do you do it?

Kim: I think it’s the same principle as with spoken language. If you know many languages, you can easily learn more languages because the next language is not very different from all other languages you already know. Many times I find new concepts, new ways of doing things that are completely different to what am I used to. Every time it is frustrating and time- consuming to learn, but every time I view everything else that I have learned in a slightly different way.

7. Can you do both front-end and back-end? If yes, what do you like the most? Why?

Kim: Yes, I am very comfortable with both. Most of the time I like to come up with solutions that can be re-used over and over again in areas that I did not expect. Due to this, I actually like both front- and back-end, since I can do this in both places.

I probably like back-end slightly more, because you can get even further back and away from traditional web development. When I worked for X client at Y employer I wrote a communication bridge between Web and Game, that was very fun and challenging, and not something you do in traditional web applications so I had to solve that problem too.

To sum up, here are the takeaways:

  • To learn how to code, you need to be curious and eager to take a few more steps to succeed. You need to ask people, to read forums and other available sources and most importantly you have to try to do it yourself. Programming is an art and a science of solving problems.
  • If you work on a product (and you’re not a developer), you don’t necessarily have to know how to program in the language the product is written in but rather understand the stack, i.e. the layers of technologies that are used to provide functionality to your product.
  • Communication is a very important part of the whole process of building a product and not only with developers but also with other teams, i.e. designers, stakeholders, clients.
  • To earn developers’ trust, you need to trust them as well. You must try not to explain how to solve your problem, you need to trust your developers and designers to make good solutions.
  • Challenge, freedom of expression, ability to improve stuff or work on something new and usefulness are the top factors for choosing a side project to work on.
  • If you want to learn a new programming language, it is not that hard if you know some fundamentals and understand how to approach it. Your brain can memorize certain schemes and structures and adapt.

Thanks for reading!

Show your support

Clapping shows how much you appreciated Maryna Blinovska’s story.