6 ms·

Practising Programming

119 points by mattpogue 4y ago

angarg12 4y ago
That's fair, but if you code for a living and growing is important for your, you should carefully evaluate where you work. Sometimes people dismiss certain companies. I remember my first boss dissing Google saying things like "how good can Google really be?". Now that I've experience it, I can say that career growth and learning between companies are not measure in percentage points or multiples, but orders of magnitude. The reason is simple: in some companies you might not learn anything or even pick up bad habits, while others will accelerate your growth. I spent the first 7 years of my career in a low performing organization. A few year later I joined a Big Tech company, and in 1 year I grew more than those 7 years combined.
- jackblemming 4y ago
  Google is a great place to grow. Just do the complete opposite of every framework Google comes out with (and then usually kills a few years later) and you'll be a star programmer.
- philipphutterer 4y ago
  What do you think is the reason for that "orders of magnitude" in growth? Can one experience similar without working for a big tech? Is it a mental thing or rather the working environment with many highly qualified people around?
  - Jensson 4y ago
    Google give you a lot of responsibility, even as a junior. When a typical agile shop gives you tasks expected to take hours, Google gives you projects expected to take weeks and tell you to drive that project. And as you grow they give you bigger and bigger tasks. So then if you need to meet someone, you contact them and schedule that meeting. If the project requires custom designs, you write that design doc. And if they add more engineers to the project, it is your job to get them up to speed and assign parts of the project to them so they can be productive. Basically, your job is to ensure things gets done.
  - angarg12 4y ago
    Mindset is necessary but not sufficient. Some environments encourage learning, while others discourage it. That's the trick behind the "orders of magnitude" sleight of hand. Is not that you learn 100 times faster in some companies (whatever that even means), but that in some places you don't learn anything at all, and in others you pick up bad habits that could count as negative learning. For example one of my previous companies was very top down, siloed and hierarchical. One time I went to talk with a PM from a different team about the prioritization of certain customer features, and my boss got really pissed off. He told me I should never talk directly with anyone and should always communicate via him. This was also the kind of place where new ideas were shut down and opposing the main point of view could get you in trouble. What about the opposite, people who have the environment but not the mindset? Some might coast years in big tech actively refusing to learn, but it is rare. Most often they will be put in situations that make them uncomfortable and will choose to leave (reorgs are common). Other times their performance will simply suffer if they aren't able to keep up with the team.
- DavidSharff 4y ago
  Are you able to compare the experience of being at a Big Tech company against a very small team with wide responsibilities? I'm in my 11th year as a developer and left a pure tech company 6 years ago where I was surrounded by other engineers for a small one where I've been 1 of a 2 until this past year (I now lead a team of 3 stateside and nominally 3 more overseas). Note for traditional startup folks: the lack of team growth may seem like an obvious signal of low performance. Fwiw - we're entirely self-funded and our revenue has grown by nearly 5x and total staff by 3-4x during that time. From a career/skill growth perspective, I often wonder how being on my little island nets out against joining a larger elite team. I've no doubt developed idiosyncrasies but I've also directly or collaboratively coded, designed, deployed, and promoted every piece of software, including several web products from scratch, that have been foundational to our success since the first year the company existed. I really have no idea how to compare that experience with being a cog in a massive machine but surrounded by brilliant work and brilliant people I could learn from.
  - arinlen 4y ago
    > Are you able to compare the experience of being at a Big Tech company compared to a very small team with wide responsibilities? Most "Big Tech companies" are already structured internally as small teams with wide responsibilities, which imclude owning multiple projects and with it everything required to develop and deploy them. If anything, "Big Tech companies" have enough resources available to allow developers to work without bothering with distractions.
    - DavidSharff 4y ago
      I think it's a good point that there are many more domains within large organizations than one might expect from the outside. However, people are undoubtedly in more specialized roles and teams on the whole. I'm merely trying to explore the differences in growth as a developer between the two extremes. While I don't think as many people who build React interfaces at Facebook are also spending days creating Postgres schema diagrams and responding to mission criticial DevOps failures, I certainly grant that the small team varied project approach might be more similar than I realize. In that case or either way, the most impactful difference in how personal growth is impacted may be the surrounding ecosystem and knowledge base. In one scenario you are flush with existing infrastructure and the thoughtful people who designed or maintain it. This can focus your work as you mentioned and is also a great learning environment. While on the other side you are working without a safety net slogging your way through creating everything* from scratch. This forces you to learn new skills in unfamiliar areas and managing all sorts of tradeoffs autonomously (there could be literally no one else to motivate you or to ask a question aside from your search bar). * Infrastructure, tools, processes, etc. I'm not talking about reinventing the wheel though you are free to do so for your own pleasure or peril.
cinntaile 4y ago
> As someone of rather limited talent, I have long been aware that if I'm not proactive about learning, I will fall even further behind where I would like to be. Then in his bio... Shopify / Royal Academy of Engineering Research Chair in Language Engineering. I guess we have wildly differing opinions on what is considered rather limited talent. But I don't want to downplay the blogpost by nitpicking here, his main point still stands.
- caslon 4y ago
  People of limited talent can still go on to do things that earn money. It's actually pretty common for gifted children to fail economically if not properly supported; someone of limited talent isn't as likely to get disproportionately unrewarded for their level of skill at early levels, which helps them later on.
- hennell 4y ago
  He might mean limited 'natutal' talent. Some people just inhale new concepts and syntax and grok it all instantly. Others of us have to really work at learning, understanding and using it before it clicks, and even then it's easy to forget if you don't use it often. But that second group can be ultimately more successful because they've learnt how to learn, the natural learner has no idea what they should do when it doesn't just click.
  - Ultimatt 4y ago
    The people groking things instantly and inhaling ideas are actually the ones who learned to learn, and everyone else just thinks they have because they put a lot of effort into broken practises of learning.
    - someweirdperson 4y ago
      There isn't much new to learn. It is mostly new wheels, but those are still wheels, just in a different box.
rdevsrex 4y ago
I resonate with this a lot. Currently, I'm the only developer at a startup. The owner is a great guy, and knows some coding, but there is no one to review my code, so it's kind of like playing chess by yourself. At my last job, I learned a lot more and could rely on more seasoned advice. It is something that I definitely miss, but we plan to hire soon, so I won't be alone forever :)
wronglyprepaid 4y ago
How about contributing to open source and doing some reviews on github? I would say it works wonders for me, it somewhat depends on the project but for the most part I think it has many positive dividends and compared to leetcode I think it gives you much more practical skills.
bibackdas 4y ago
eternityforest 4y ago
I don't believe programming is anything like other skills(That's why I love tech jobs!). There's no muscle memory strictly needed. No precise memorization. There's none of what I call "atomic time regions" where once you start, everything has to be right or the whole thing is considered a failure(Think of calligraphy and how one bad move can ruin a piece). Instead there's just a small amount of base knowledge every coder needs, plus vague familiarity with frameworks, and a general sense of what will possibly screw you over later(Anyone can write most programs that don't involve novel math or algorithms, the challenge is in making them not screw you over somehow). If a world champion level programmer makes a basic app in Vue, it will maybe be 20% better than mine, because... modern programming is all about providing obviously ways to do common things. There's not much variation possibly in something so completely technical. If we both design 100kloc apps, his(hers?) will be a lot better. There design choices in that kind of thing that don't come up at all in a 1 day project. Sports people say you play how you practice, right? So there's only one kind of technical practice I care about. The kind that is similar to production code. Either in scope and scale, or depth of crazy algorithmic math, or any other way, but if it doesn't replicate production... is it really practice? Guitar plays have a concept called "Noodling", defined as playing guitar... but not really playing something. It might sound OK, but you can kind of feel that it's not really helping you towards being able to play that song you want to play, the way you actually want to play it. It's widely considered not really practice. Almost like scrolling Facebook compared to reading a book, like I should be doing instead of scrolling Hacker News.... I don't make any effort to practice programming unless I want to learn a specific new technology. I just do projects that I think are worth doing, and resemble the stuff I want to do in the future, and I try to do them well without hackery.
- el_oni 4y ago
  Yeah, when i practice programming its normally a toy version of something thats been bouncing around my head for an actual project. And normally something that i would like to learn for myself or a curiosity about how something works. Generally outside of work hours I'll throw together a vague example and validate that the idea is something that works and get vaguely familiar with the libraries involved. That way when I go to build it at work I don't start from zero. If its for a personal project i just noodle in a repl or ide on a branch
mkl95 4y ago
> When we see a world-class musician flawlessly play challenging music, it can be tempting to imagine that they were always able to do so. A moment's thought makes it obvious that they must have had to spend huge amounts of time practising basic techniques in order to reach that level. What's less obvious is that they have to continue spending considerable amounts of time simply to maintain that technique, let alone expand it. The average SaaS engineering job is akin to recording a different concert for several hours every day, with no time to tune your instruments and little investment to fix or replace them. Even if the orchestra is out of tune, the conductor won't necessarily notice or care because his job is not to actually conduct the orchestra. In fact, he doesn't understand music, he just knows how to request and deliver recordings. At times he pretends to understand music, which mostly involves flailing his arms spastically while musicians do their best at not minding him. After 8 hours where only a couple were actually spent playing and the rest were spent arguing and debating how to play music with the conductor and the audience, musicians are left exhausted, with no energy to improve their skills.
- froh 4y ago
  You may want to watch a number of Benjamin Zander's YouTube videos and revise your statement. I share your frustration on feature pressure with no official room for practice and refactoring however the metaphor about the role of a conductor is completely off. A conductor knows and understands music, deeply, a d they connect the dots and coordinate the orchestra and zoom into lots of little details while improving the big picture.
  - mkl95 4y ago
    The conductor in my comment is a project / engineering manager and is meant to show how bad OP's analogy is.
    - froh 4y ago
      The article is talking about deliberate practice at an individual level. No conductor, no orchestra, no collaboration. I agree there are incompetent men-in-the-middle managers who make things worse. It didn't occur to me to think about that in the context if the article, plus, I've had the joy if working with excellent project managers, too. So the bad conductor ex machina didn't click with me.
ChrisMarshallNY 4y ago
> Instead, I've found that real-world tasks that require me to do something new are where I most improve, and most enjoy improving, my programming skills. I liked this, but then they went on about automating their workflow (which is a great application of skills. They are correct). It's just that I don't have a workflow that really benefits from automation. Whenever I introduce scripting and automation, I usually end up with concrete galoshes[0], and nothing is really gained. My automation is generally a run of SwiftLint, before compiling. I also automate Jazzy doc building. Other than that, I tend to be pretty manual, even for large projects, with repeated releases. What I do, is ship often, and write Swift every day. I've been writing Swift every day for the last few years. I probably passed the "10,000 hours" mark, at least a couple of years ago. My GH ID Activity Graph[1] is solid green, and it's not "gamed," like so many people do with theirs. I just write a lot of code; every single day. I also like to ship stuff. That means actually doing what is necessary to move it out into the world. Push it out of the nest, so to speak. Lots of "boring" stuff, involved with that. But I have found, that if you do it all the time, it basically becomes "muscle memory." When folks look at the code I write, they assume that I'm a slow, plodding programmer, because of all the structure and code docs. Nothing could be farther from the truth. I write a lot of really high-Quality code; very quickly. It's just habit. [0] https://littlegreenviper.com/miscellany/concrete-galoshes/ https://littlegreenviper.com/miscellany/concrete-galoshes/ [1] https://github.com/ChrisMarshallNY#github-stuff https://github.com/ChrisMarshallNY#github-stuff
jjice 4y ago
I interned at a retail company ad a software engineer when I was in college, and thought hat a sophomore in college knew everything they needed to about programming to work there. I still believe that's but there are so many other skills to be had there. Now that I'm full time at a start up, I've learned so much in the past year, not just about programming, but more about design, testing, tradeoffs, business, and DevOps. The amount of skills a software engineer needs is much less of just programming than I thought. So many soft skills involved, so much design, so much practice and iteration. It's absolutely amazing to see how much there is to learn. I can't see myself at that retail company again, just because everything was slow. They had very stable services and ops, no doubt, but since there was already a group of people to handle that task, I never learned it. At a start up, I need to do everything, and I love it so far. That said, I can see it becoming overbearing at a certain point and wanting that slow down eventually, but I'll play it by ear. It's a great industry to be a part of, and as a young developer, it's a very exciting future.
timoteostewart 4y ago
I try to do a few LeetCode problems a day as my own take on the “coding kata” idea. There is really a pretty small set of problems and subproblems that crop up over and over again in LC problems, so stuff like building a tree or graph traversal or performing a string or array transformation become very well worn and familiar tools.
- agumonkey 4y ago
  I was wondering what one could do after finishing leetcode (not that I did), do you have any idea ? reading publications / journals to find new algorithms to study ? ps: thanks for the nice suggestions folks :)
  - ansk0 4y ago
    If you like maths then project euler problems can be quite fun. I'd also recommend https://codecrafters.io/ https://codecrafters.io/ - I did the Redis challenge recently while trying to (re)learn Java and it was a good experience.
    - timoteostewart 4y ago
      Wow, codecrafters.io looks fascinating. Thanks!
  - timoteostewart 4y ago
    Good question. LC mainly deals in general-purpose algorithms, so if you're getting diminishing returns there, then my advice would be to probe your domain specialty for niche algorithms or data structures. That might mean journals or online communities. Like I'm sure there are hangouts for machine learning (ML) folks, for functional programming (FP) folks, for automation nerds, and so on where algorithms and approaches relevant to the niche are bandied about. Another option is to use the LC problems as a test bed for your own exploration and "play" with solving problems. For example, I'm a nerd for optimizing algorithms and for practicing Java-style (not Smalltalk-style) object-oriented programming (OOP). So sometimes I'll find a way to optimize the LC problem in an interesting way. Or I'll deliberately use an OOP approach. Here are a few examples from the past week of me doing things like this on LC. Maybe it'll inspire you to hone your own particular interests in some way. https://leetcode.com/problems/search-a-2d-matrix/discuss/1977268/java-0ms-beats-100-uses-custom-pseudoarray-class-that-turns-matrix-into-array https://leetcode.com/problems/search-a-2d-matrix/discuss/197... https://leetcode.com/problems/find-the-distance-value-between-two-arrays/discuss/1974248/java-2ms-beats-995-decompose-abs-into-comparisons-against-precomputed-arrays https://leetcode.com/problems/find-the-distance-value-betwee... https://leetcode.com/problems/count-sub-islands/discuss/1974436/java-beats-5-uses-object-oriented-approach-custom-classes-for-island-and-cell https://leetcode.com/problems/count-sub-islands/discuss/1974...

119 points by mattpogue 4y ago

That's fair, but if you code for a living and growing is important for your, you should carefully evaluate where you work. Sometimes people dismiss certain companies. I remember my first boss dissing Google saying things like "how good can Google really be?". Now that I've experience it, I can say that career growth and learning between companies are not measure in percentage points or multiples, but orders of magnitude. The reason is simple: in some companies you might not learn anything or even pick up bad habits, while others will accelerate your growth. I spent the first 7 years of my career in a low performing organization. A few year later I joined a Big Tech company, and in 1 year I grew more than those 7 years combined.

jackblemming 4y ago
Google is a great place to grow. Just do the complete opposite of every framework Google comes out with (and then usually kills a few years later) and you'll be a star programmer.
philipphutterer 4y ago
What do you think is the reason for that "orders of magnitude" in growth? Can one experience similar without working for a big tech? Is it a mental thing or rather the working environment with many highly qualified people around?
- Jensson 4y ago
  Google give you a lot of responsibility, even as a junior. When a typical agile shop gives you tasks expected to take hours, Google gives you projects expected to take weeks and tell you to drive that project. And as you grow they give you bigger and bigger tasks. So then if you need to meet someone, you contact them and schedule that meeting. If the project requires custom designs, you write that design doc. And if they add more engineers to the project, it is your job to get them up to speed and assign parts of the project to them so they can be productive. Basically, your job is to ensure things gets done.
- angarg12 4y ago
  Mindset is necessary but not sufficient. Some environments encourage learning, while others discourage it. That's the trick behind the "orders of magnitude" sleight of hand. Is not that you learn 100 times faster in some companies (whatever that even means), but that in some places you don't learn anything at all, and in others you pick up bad habits that could count as negative learning. For example one of my previous companies was very top down, siloed and hierarchical. One time I went to talk with a PM from a different team about the prioritization of certain customer features, and my boss got really pissed off. He told me I should never talk directly with anyone and should always communicate via him. This was also the kind of place where new ideas were shut down and opposing the main point of view could get you in trouble. What about the opposite, people who have the environment but not the mindset? Some might coast years in big tech actively refusing to learn, but it is rare. Most often they will be put in situations that make them uncomfortable and will choose to leave (reorgs are common). Other times their performance will simply suffer if they aren't able to keep up with the team.
DavidSharff 4y ago
Are you able to compare the experience of being at a Big Tech company against a very small team with wide responsibilities? I'm in my 11th year as a developer and left a pure tech company 6 years ago where I was surrounded by other engineers for a small one where I've been 1 of a 2 until this past year (I now lead a team of 3 stateside and nominally 3 more overseas). Note for traditional startup folks: the lack of team growth may seem like an obvious signal of low performance. Fwiw - we're entirely self-funded and our revenue has grown by nearly 5x and total staff by 3-4x during that time. From a career/skill growth perspective, I often wonder how being on my little island nets out against joining a larger elite team. I've no doubt developed idiosyncrasies but I've also directly or collaboratively coded, designed, deployed, and promoted every piece of software, including several web products from scratch, that have been foundational to our success since the first year the company existed. I really have no idea how to compare that experience with being a cog in a massive machine but surrounded by brilliant work and brilliant people I could learn from.
- arinlen 4y ago
  > Are you able to compare the experience of being at a Big Tech company compared to a very small team with wide responsibilities? Most "Big Tech companies" are already structured internally as small teams with wide responsibilities, which imclude owning multiple projects and with it everything required to develop and deploy them. If anything, "Big Tech companies" have enough resources available to allow developers to work without bothering with distractions.
  - DavidSharff 4y ago
    I think it's a good point that there are many more domains within large organizations than one might expect from the outside. However, people are undoubtedly in more specialized roles and teams on the whole. I'm merely trying to explore the differences in growth as a developer between the two extremes. While I don't think as many people who build React interfaces at Facebook are also spending days creating Postgres schema diagrams and responding to mission criticial DevOps failures, I certainly grant that the small team varied project approach might be more similar than I realize. In that case or either way, the most impactful difference in how personal growth is impacted may be the surrounding ecosystem and knowledge base. In one scenario you are flush with existing infrastructure and the thoughtful people who designed or maintain it. This can focus your work as you mentioned and is also a great learning environment. While on the other side you are working without a safety net slogging your way through creating everything* from scratch. This forces you to learn new skills in unfamiliar areas and managing all sorts of tradeoffs autonomously (there could be literally no one else to motivate you or to ask a question aside from your search bar). * Infrastructure, tools, processes, etc. I'm not talking about reinventing the wheel though you are free to do so for your own pleasure or peril.

cinntaile 4y ago

> As someone of rather limited talent, I have long been aware that if I'm not proactive about learning, I will fall even further behind where I would like to be. Then in his bio... Shopify / Royal Academy of Engineering Research Chair in Language Engineering. I guess we have wildly differing opinions on what is considered rather limited talent. But I don't want to downplay the blogpost by nitpicking here, his main point still stands.

caslon 4y ago
People of limited talent can still go on to do things that earn money. It's actually pretty common for gifted children to fail economically if not properly supported; someone of limited talent isn't as likely to get disproportionately unrewarded for their level of skill at early levels, which helps them later on.
hennell 4y ago
He might mean limited 'natutal' talent. Some people just inhale new concepts and syntax and grok it all instantly. Others of us have to really work at learning, understanding and using it before it clicks, and even then it's easy to forget if you don't use it often. But that second group can be ultimately more successful because they've learnt how to learn, the natural learner has no idea what they should do when it doesn't just click.
- Ultimatt 4y ago
  The people groking things instantly and inhaling ideas are actually the ones who learned to learn, and everyone else just thinks they have because they put a lot of effort into broken practises of learning.
  - someweirdperson 4y ago
    There isn't much new to learn. It is mostly new wheels, but those are still wheels, just in a different box.

rdevsrex 4y ago

I resonate with this a lot. Currently, I'm the only developer at a startup. The owner is a great guy, and knows some coding, but there is no one to review my code, so it's kind of like playing chess by yourself. At my last job, I learned a lot more and could rely on more seasoned advice. It is something that I definitely miss, but we plan to hire soon, so I won't be alone forever :)

wronglyprepaid 4y ago

How about contributing to open source and doing some reviews on github? I would say it works wonders for me, it somewhat depends on the project but for the most part I think it has many positive dividends and compared to leetcode I think it gives you much more practical skills.

bibackdas 4y ago

eternityforest 4y ago

I don't believe programming is anything like other skills(That's why I love tech jobs!). There's no muscle memory strictly needed. No precise memorization. There's none of what I call "atomic time regions" where once you start, everything has to be right or the whole thing is considered a failure(Think of calligraphy and how one bad move can ruin a piece). Instead there's just a small amount of base knowledge every coder needs, plus vague familiarity with frameworks, and a general sense of what will possibly screw you over later(Anyone can write most programs that don't involve novel math or algorithms, the challenge is in making them not screw you over somehow). If a world champion level programmer makes a basic app in Vue, it will maybe be 20% better than mine, because... modern programming is all about providing obviously ways to do common things. There's not much variation possibly in something so completely technical. If we both design 100kloc apps, his(hers?) will be a lot better. There design choices in that kind of thing that don't come up at all in a 1 day project. Sports people say you play how you practice, right? So there's only one kind of technical practice I care about. The kind that is similar to production code. Either in scope and scale, or depth of crazy algorithmic math, or any other way, but if it doesn't replicate production... is it really practice? Guitar plays have a concept called "Noodling", defined as playing guitar... but not really playing something. It might sound OK, but you can kind of feel that it's not really helping you towards being able to play that song you want to play, the way you actually want to play it. It's widely considered not really practice. Almost like scrolling Facebook compared to reading a book, like I should be doing instead of scrolling Hacker News.... I don't make any effort to practice programming unless I want to learn a specific new technology. I just do projects that I think are worth doing, and resemble the stuff I want to do in the future, and I try to do them well without hackery.

el_oni 4y ago
Yeah, when i practice programming its normally a toy version of something thats been bouncing around my head for an actual project. And normally something that i would like to learn for myself or a curiosity about how something works. Generally outside of work hours I'll throw together a vague example and validate that the idea is something that works and get vaguely familiar with the libraries involved. That way when I go to build it at work I don't start from zero. If its for a personal project i just noodle in a repl or ide on a branch

mkl95 4y ago

> When we see a world-class musician flawlessly play challenging music, it can be tempting to imagine that they were always able to do so. A moment's thought makes it obvious that they must have had to spend huge amounts of time practising basic techniques in order to reach that level. What's less obvious is that they have to continue spending considerable amounts of time simply to maintain that technique, let alone expand it. The average SaaS engineering job is akin to recording a different concert for several hours every day, with no time to tune your instruments and little investment to fix or replace them. Even if the orchestra is out of tune, the conductor won't necessarily notice or care because his job is not to actually conduct the orchestra. In fact, he doesn't understand music, he just knows how to request and deliver recordings. At times he pretends to understand music, which mostly involves flailing his arms spastically while musicians do their best at not minding him. After 8 hours where only a couple were actually spent playing and the rest were spent arguing and debating how to play music with the conductor and the audience, musicians are left exhausted, with no energy to improve their skills.

froh 4y ago
You may want to watch a number of Benjamin Zander's YouTube videos and revise your statement. I share your frustration on feature pressure with no official room for practice and refactoring however the metaphor about the role of a conductor is completely off. A conductor knows and understands music, deeply, a d they connect the dots and coordinate the orchestra and zoom into lots of little details while improving the big picture.
- mkl95 4y ago
  The conductor in my comment is a project / engineering manager and is meant to show how bad OP's analogy is.
  - froh 4y ago
    The article is talking about deliberate practice at an individual level. No conductor, no orchestra, no collaboration. I agree there are incompetent men-in-the-middle managers who make things worse. It didn't occur to me to think about that in the context if the article, plus, I've had the joy if working with excellent project managers, too. So the bad conductor ex machina didn't click with me.

ChrisMarshallNY 4y ago

> Instead, I've found that real-world tasks that require me to do something new are where I most improve, and most enjoy improving, my programming skills. I liked this, but then they went on about automating their workflow (which is a great application of skills. They are correct). It's just that I don't have a workflow that really benefits from automation. Whenever I introduce scripting and automation, I usually end up with concrete galoshes[0], and nothing is really gained. My automation is generally a run of SwiftLint, before compiling. I also automate Jazzy doc building. Other than that, I tend to be pretty manual, even for large projects, with repeated releases. What I do, is ship often, and write Swift every day. I've been writing Swift every day for the last few years. I probably passed the "10,000 hours" mark, at least a couple of years ago. My GH ID Activity Graph[1] is solid green, and it's not "gamed," like so many people do with theirs. I just write a lot of code; every single day. I also like to ship stuff. That means actually doing what is necessary to move it out into the world. Push it out of the nest, so to speak. Lots of "boring" stuff, involved with that. But I have found, that if you do it all the time, it basically becomes "muscle memory." When folks look at the code I write, they assume that I'm a slow, plodding programmer, because of all the structure and code docs. Nothing could be farther from the truth. I write a lot of really high-Quality code; very quickly. It's just habit. [0] https://littlegreenviper.com/miscellany/concrete-galoshes/ https://littlegreenviper.com/miscellany/concrete-galoshes/ [1] https://github.com/ChrisMarshallNY#github-stuff https://github.com/ChrisMarshallNY#github-stuff

jjice 4y ago

I interned at a retail company ad a software engineer when I was in college, and thought hat a sophomore in college knew everything they needed to about programming to work there. I still believe that's but there are so many other skills to be had there. Now that I'm full time at a start up, I've learned so much in the past year, not just about programming, but more about design, testing, tradeoffs, business, and DevOps. The amount of skills a software engineer needs is much less of just programming than I thought. So many soft skills involved, so much design, so much practice and iteration. It's absolutely amazing to see how much there is to learn. I can't see myself at that retail company again, just because everything was slow. They had very stable services and ops, no doubt, but since there was already a group of people to handle that task, I never learned it. At a start up, I need to do everything, and I love it so far. That said, I can see it becoming overbearing at a certain point and wanting that slow down eventually, but I'll play it by ear. It's a great industry to be a part of, and as a young developer, it's a very exciting future.

timoteostewart 4y ago

I try to do a few LeetCode problems a day as my own take on the “coding kata” idea. There is really a pretty small set of problems and subproblems that crop up over and over again in LC problems, so stuff like building a tree or graph traversal or performing a string or array transformation become very well worn and familiar tools.

agumonkey 4y ago
I was wondering what one could do after finishing leetcode (not that I did), do you have any idea ? reading publications / journals to find new algorithms to study ? ps: thanks for the nice suggestions folks :)
- ansk0 4y ago
  If you like maths then project euler problems can be quite fun. I'd also recommend https://codecrafters.io/ https://codecrafters.io/ - I did the Redis challenge recently while trying to (re)learn Java and it was a good experience.
  - timoteostewart 4y ago
    Wow, codecrafters.io looks fascinating. Thanks!
- timoteostewart 4y ago
  Good question. LC mainly deals in general-purpose algorithms, so if you're getting diminishing returns there, then my advice would be to probe your domain specialty for niche algorithms or data structures. That might mean journals or online communities. Like I'm sure there are hangouts for machine learning (ML) folks, for functional programming (FP) folks, for automation nerds, and so on where algorithms and approaches relevant to the niche are bandied about. Another option is to use the LC problems as a test bed for your own exploration and "play" with solving problems. For example, I'm a nerd for optimizing algorithms and for practicing Java-style (not Smalltalk-style) object-oriented programming (OOP). So sometimes I'll find a way to optimize the LC problem in an interesting way. Or I'll deliberately use an OOP approach. Here are a few examples from the past week of me doing things like this on LC. Maybe it'll inspire you to hone your own particular interests in some way. https://leetcode.com/problems/search-a-2d-matrix/discuss/1977268/java-0ms-beats-100-uses-custom-pseudoarray-class-that-turns-matrix-into-array https://leetcode.com/problems/search-a-2d-matrix/discuss/197... https://leetcode.com/problems/find-the-distance-value-between-two-arrays/discuss/1974248/java-2ms-beats-995-decompose-abs-into-comparisons-against-precomputed-arrays https://leetcode.com/problems/find-the-distance-value-betwee... https://leetcode.com/problems/count-sub-islands/discuss/1974436/java-beats-5-uses-object-oriented-approach-custom-classes-for-island-and-cell https://leetcode.com/problems/count-sub-islands/discuss/1974...