6 ms·

Professional Programming: The First 10 Years

131 points by keegancsmith 4y ago

gombosg 4y ago
Awesome article! > Typing can be the bottleneck Agree! Learning touch typing (at 30 :)) was a big relief for my fingers and wrists. Also it's important to have a good mechanical or scissor keyboard so that typing actually feels good. > Hiring is hard And it's like dating: you only get to know the people who you actually hire and never learn what would have happened to the people that you have rejected. That is some selection bias in the system.
terrycrowley 4y ago
Great article. The point about fearlessness resonated. Ray Tomlinson (wrote the first inter-machine email, picked the @ symbol, helped design TCP) was one of the best and most fearless engineers I ever worked with.
calderwoodra 4y ago
Amazing post, thanks for putting this together. Three points I think are undervalued in my experience: > Typing can be the bottleneck > The most important trait in developers: rolling up their sleeves because it has to get done > Nothing really matters, except bringing value to the customer I often feel the code needed to deliver value is not that complex and most senior folks can do it, but in an effort to "save time" on typing, they try to design something complex and debate endlessly, when what's really needed is rolling up your sleeves, getting it done, then saying "oh that? I finished coding it and it works, let's ship it already" (edit: formatting)
- benkwokcy 4y ago
  I think the author was being a tiny bit hyperbolic saying "nothing really matters but value for the customer". In a restaurant kitchen, the goal is to get food into the customer's mouth... but you still want to keep your knives clean and tidy. Of course, keeping them tidy isn't the point of the restaurant either.
brundolf 4y ago
This is a gem: > When you’re glueing other people’s code together, there’s a very real danger that the glue is where complexity will accumulate. But glue code is the last place where you want your complexity to live. It hides complexity. What you want is to make complexity as visible as you can, shining a light on it with the hope that it turns into dust and disappears.
svilen_dobrev 4y ago
thank you for writing this. i am programming (and-all-that-goes-with-it = mostly-mentoring, both downwards and upwards) for 35 years... and it is somewhat difficult for me to tell the things you wrote there, to my pupils/students/team/s, because i have kind-of found them loooong time ago, and since then have much further understanding, and now i consider them obvious/intrinsic and don't even think about them... and they are not obvious at all. And yes, i still love programmming very much (although sometimes it is about programming the people. But not direct, it's more like building a language, to enable further things with it :). Now, if it's only one thing from me: it's all about people. okay, Mostly about some-people somewhere in the chain. Not about code/architecture/.... have fun www.svilendobrev.com
benniomars 4y ago
I agree with this article 100%. Got 14 years in the field and I've come to the same conclusions as well.
danielvaughn 4y ago
The point about other people's code rings true for me. What I've been trying to do is gather a collection of good code I've written over the years - solutions that can work for a variety of problems. They're like my own little npm packages, except I have full access to the source and completely understand them inside and out. I can also completely explain how they work to my team, and how they can make changes to the behavior if need be.
- gryn 4y ago
  A lot of the time it's not characteristics of the code itself but the business mission it needs to fulfill. good code can give you a lot of headaches if the external business environment sees qualitative changes while that sloppy code over there is has being going hassle free for the last 6 years because the end-goal and patterns that it needs to fulfill didn't change much during that period.
troelsSteegin 4y ago
"Code has mass". Following from that, attention is force and understanding is acceleration.
- nh23423fefe 4y ago
  No I dont think that follows. Forces don't cause accelerations. But attention is required for understanding. > Every additional line of code you don’t need is ballast. It weighs your codebase down, making it harder to steer and change direction if you need to So code as mass is the scalar part of the momentum. So the directional part is where this code is going in "purpose space".
- kqr 4y ago
  Code has mass has another interesting corollary: large enough collections of code tends to almost gravitationally attract more code. This results in god classes and those huge libraries of diverse functionality that usually go by the name "misc" or "util". The mechanism for this is fairly obvious: it is usually convenient to put new functionality next to existing one because it allows you to reuse things that maybe should not be reused. The more diverse a big lump of code, the more potential future functionality is convenient to add to the lump. This is a reason to be very vigilant against this type of accidental reuse and incohesive modules. It's a reinforcing feedback loop that needs a balancing mechanism.
- dokem 4y ago
  I think understanding would be velocity. Acceleration would be change in understanding, which is proportional to attention.
derekstride 4y ago
> Look at that little program go, holding the internet together, despite the 17 TODOs in it. This hit a little too close to home.
ctvo 4y ago
> Fearlessness is undervalued Being technically fearless is also a trait I've identified in engineers I enjoy working with. It's hard to quantify how you gain this. I think it's a combination of strong fundamentals and deep curiosity. It forms when things stop being magic.
- humbleMouse 4y ago
  This is what I tell anyone trying to learn programming or any computer related craft. The first step is to not be afraid of the computer. Only then you can learn.
- robervin 4y ago
  Absolutely agree, but I like to think the magic bit can stick around as wonder. Perhaps that's bundled into deep curiosity.
- albertzeyer 4y ago
  I observed that many people are really afraid even of basic things. "I don't want to click here because I don't know what it does. Maybe it breaks my computer or deletes all my stuff." Maybe it's because I started using computers as a child (~9 years old or so) but I always had the mindset to just try things out. You cannot really break the computer or delete stuff. Every tool will always put a very clear warning before you do sth stupid. And if you are really unsure with some action, just make a backup before. Reinstalling Windows every so often was anyway the norm in my youth. And just trying things out, clicking through the menu, through the actions, just playing around, make some dummy playground, this is often how I discovered the functionality of most tools. This is a very effective way to get familiar with most tools. But others, when they say they don't know how to do X in tool Y, they never have just tried around. And when I ask them why they have not, they tell me that they are afraid of breaking or deleting sth. With coding, it's very much the same. And now that we have Git, with some backup somewhere remote, and hopefully a test suite, maybe even with CI, it's even much less of an issue if you break sth because it always can be undone and you normally should notice with the tests (or if you don't, you can blame the incomplete tests). Btw, regarding reading other code bases: I very much can recommend that. You will most likely learn a lot. And there are many great open source projects where you can just dive in.
civilized 4y ago
A lot of really good stuff here, for example reaffirming YAGNI and a focus on customer value. One part I think falls short: > Negativity begets negativity I think this is coming from a very common and fundamentally misguided premise - the obsessive focus on emotional valence, on whether we're being positive or negative. The real problem is not whether we are being positive or negative, it's the rush to attach emotional valence to things we have not adequately understood or described. As C. S. Lewis said, "the human mind is generally far more eager to praise and dispraise than to describe and define. It wants to make every distinction a distinction of value." This rush to emotional endpoints is the root of both toxic negativity and toxic positivity. Instead of taking positivity and negativity as endpoints, take them as prompts to better understand your surroundings. You are feeling bad about something - why? What about it makes you feel that way? Would improving it cost more than it would benefit? Is it the least bad of the alternatives? A willingness to feel and acknowledge and investigate your negative emotions is a superpower. It gives you x-ray vision into things that very few other people have. They look away from problems and let them fester because they've been taught to be allergic to negativity. The ability to look at problems is inseparable from what the author points out is a very important trait, the ability to roll up your sleeves and get stuff done.
- AnimalMuppet 4y ago
  People are emotional, at least to some degree. Most people find emotions contagious. If you're surrounded by people being negative, it's draining, even if you don't give in to the negativity. One think I would say the article is wrong on, though - snark doesn't have to lead to cynicism. At my place, we talk a fair amount of smack, but it's just entertainment. (One difference - the smack is self-directed at least as often as it's directed at any particular other person.)
  - civilized 4y ago
    On the other hand, if you model productive negative thinking and communication, people will be relieved that they have the space to express their problems, and you will accelerate genuine team bonding and psychological safety. I have success stories from my personal experience doing this.
kderbyma 4y ago
Always leave something unfinished at the end of the day -- definitely helps me get focused the next day
lysecret 4y ago
Really enjoy the fearlessness. I wanted to share my main guide for programming, my dad always told it to me it comes from KentBeck: First, you make it run. Then you make it right. It is a bit connected to fearlessness, because you need to be a little fearless to start something without knowing where it will go. I think fearlessness originates from a trust in oneself, and maybe the universe too haha

131 points by keegancsmith 4y ago

Awesome article! > Typing can be the bottleneck Agree! Learning touch typing (at 30 :)) was a big relief for my fingers and wrists. Also it's important to have a good mechanical or scissor keyboard so that typing actually feels good. > Hiring is hard And it's like dating: you only get to know the people who you actually hire and never learn what would have happened to the people that you have rejected. That is some selection bias in the system.

terrycrowley 4y ago

Great article. The point about fearlessness resonated. Ray Tomlinson (wrote the first inter-machine email, picked the @ symbol, helped design TCP) was one of the best and most fearless engineers I ever worked with.

calderwoodra 4y ago

Amazing post, thanks for putting this together. Three points I think are undervalued in my experience: > Typing can be the bottleneck > The most important trait in developers: rolling up their sleeves because it has to get done > Nothing really matters, except bringing value to the customer I often feel the code needed to deliver value is not that complex and most senior folks can do it, but in an effort to "save time" on typing, they try to design something complex and debate endlessly, when what's really needed is rolling up your sleeves, getting it done, then saying "oh that? I finished coding it and it works, let's ship it already" (edit: formatting)

benkwokcy 4y ago
I think the author was being a tiny bit hyperbolic saying "nothing really matters but value for the customer". In a restaurant kitchen, the goal is to get food into the customer's mouth... but you still want to keep your knives clean and tidy. Of course, keeping them tidy isn't the point of the restaurant either.

brundolf 4y ago

This is a gem: > When you’re glueing other people’s code together, there’s a very real danger that the glue is where complexity will accumulate. But glue code is the last place where you want your complexity to live. It hides complexity. What you want is to make complexity as visible as you can, shining a light on it with the hope that it turns into dust and disappears.

svilen_dobrev 4y ago

thank you for writing this. i am programming (and-all-that-goes-with-it = mostly-mentoring, both downwards and upwards) for 35 years... and it is somewhat difficult for me to tell the things you wrote there, to my pupils/students/team/s, because i have kind-of found them loooong time ago, and since then have much further understanding, and now i consider them obvious/intrinsic and don't even think about them... and they are not obvious at all. And yes, i still love programmming very much (although sometimes it is about programming the people. But not direct, it's more like building a language, to enable further things with it :). Now, if it's only one thing from me: it's all about people. okay, Mostly about some-people somewhere in the chain. Not about code/architecture/.... have fun www.svilendobrev.com

benniomars 4y ago

I agree with this article 100%. Got 14 years in the field and I've come to the same conclusions as well.

danielvaughn 4y ago

The point about other people's code rings true for me. What I've been trying to do is gather a collection of good code I've written over the years - solutions that can work for a variety of problems. They're like my own little npm packages, except I have full access to the source and completely understand them inside and out. I can also completely explain how they work to my team, and how they can make changes to the behavior if need be.

gryn 4y ago
A lot of the time it's not characteristics of the code itself but the business mission it needs to fulfill. good code can give you a lot of headaches if the external business environment sees qualitative changes while that sloppy code over there is has being going hassle free for the last 6 years because the end-goal and patterns that it needs to fulfill didn't change much during that period.

troelsSteegin 4y ago

"Code has mass". Following from that, attention is force and understanding is acceleration.

nh23423fefe 4y ago
No I dont think that follows. Forces don't cause accelerations. But attention is required for understanding. > Every additional line of code you don’t need is ballast. It weighs your codebase down, making it harder to steer and change direction if you need to So code as mass is the scalar part of the momentum. So the directional part is where this code is going in "purpose space".
kqr 4y ago
Code has mass has another interesting corollary: large enough collections of code tends to almost gravitationally attract more code. This results in god classes and those huge libraries of diverse functionality that usually go by the name "misc" or "util". The mechanism for this is fairly obvious: it is usually convenient to put new functionality next to existing one because it allows you to reuse things that maybe should not be reused. The more diverse a big lump of code, the more potential future functionality is convenient to add to the lump. This is a reason to be very vigilant against this type of accidental reuse and incohesive modules. It's a reinforcing feedback loop that needs a balancing mechanism.
dokem 4y ago
I think understanding would be velocity. Acceleration would be change in understanding, which is proportional to attention.

derekstride 4y ago

> Look at that little program go, holding the internet together, despite the 17 TODOs in it. This hit a little too close to home.

ctvo 4y ago

> Fearlessness is undervalued Being technically fearless is also a trait I've identified in engineers I enjoy working with. It's hard to quantify how you gain this. I think it's a combination of strong fundamentals and deep curiosity. It forms when things stop being magic.

humbleMouse 4y ago
This is what I tell anyone trying to learn programming or any computer related craft. The first step is to not be afraid of the computer. Only then you can learn.
robervin 4y ago
Absolutely agree, but I like to think the magic bit can stick around as wonder. Perhaps that's bundled into deep curiosity.
albertzeyer 4y ago
I observed that many people are really afraid even of basic things. "I don't want to click here because I don't know what it does. Maybe it breaks my computer or deletes all my stuff." Maybe it's because I started using computers as a child (~9 years old or so) but I always had the mindset to just try things out. You cannot really break the computer or delete stuff. Every tool will always put a very clear warning before you do sth stupid. And if you are really unsure with some action, just make a backup before. Reinstalling Windows every so often was anyway the norm in my youth. And just trying things out, clicking through the menu, through the actions, just playing around, make some dummy playground, this is often how I discovered the functionality of most tools. This is a very effective way to get familiar with most tools. But others, when they say they don't know how to do X in tool Y, they never have just tried around. And when I ask them why they have not, they tell me that they are afraid of breaking or deleting sth. With coding, it's very much the same. And now that we have Git, with some backup somewhere remote, and hopefully a test suite, maybe even with CI, it's even much less of an issue if you break sth because it always can be undone and you normally should notice with the tests (or if you don't, you can blame the incomplete tests). Btw, regarding reading other code bases: I very much can recommend that. You will most likely learn a lot. And there are many great open source projects where you can just dive in.

civilized 4y ago

A lot of really good stuff here, for example reaffirming YAGNI and a focus on customer value. One part I think falls short: > Negativity begets negativity I think this is coming from a very common and fundamentally misguided premise - the obsessive focus on emotional valence, on whether we're being positive or negative. The real problem is not whether we are being positive or negative, it's the rush to attach emotional valence to things we have not adequately understood or described. As C. S. Lewis said, "the human mind is generally far more eager to praise and dispraise than to describe and define. It wants to make every distinction a distinction of value." This rush to emotional endpoints is the root of both toxic negativity and toxic positivity. Instead of taking positivity and negativity as endpoints, take them as prompts to better understand your surroundings. You are feeling bad about something - why? What about it makes you feel that way? Would improving it cost more than it would benefit? Is it the least bad of the alternatives? A willingness to feel and acknowledge and investigate your negative emotions is a superpower. It gives you x-ray vision into things that very few other people have. They look away from problems and let them fester because they've been taught to be allergic to negativity. The ability to look at problems is inseparable from what the author points out is a very important trait, the ability to roll up your sleeves and get stuff done.

AnimalMuppet 4y ago
People are emotional, at least to some degree. Most people find emotions contagious. If you're surrounded by people being negative, it's draining, even if you don't give in to the negativity. One think I would say the article is wrong on, though - snark doesn't have to lead to cynicism. At my place, we talk a fair amount of smack, but it's just entertainment. (One difference - the smack is self-directed at least as often as it's directed at any particular other person.)
- civilized 4y ago
  On the other hand, if you model productive negative thinking and communication, people will be relieved that they have the space to express their problems, and you will accelerate genuine team bonding and psychological safety. I have success stories from my personal experience doing this.

kderbyma 4y ago

Always leave something unfinished at the end of the day -- definitely helps me get focused the next day

lysecret 4y ago

Really enjoy the fearlessness. I wanted to share my main guide for programming, my dad always told it to me it comes from KentBeck: First, you make it run. Then you make it right. It is a bit connected to fearlessness, because you need to be a little fearless to start something without knowing where it will go. I think fearlessness originates from a trust in oneself, and maybe the universe too haha