Ask HN: What took you from being a good programmer to a great one?
37 comments
Almost all programmers work in frameworks or on top of a large pile of abstractions. I e.g. talk about web frameworks, database frameworks, cryptographic libraries, graphics programming toolkits...
To become great, look what's underneath each abstraction and see how many layers down you can go and still understand stuff. Try to build your own abstractions from the ground up, e.g. write an ORM, write an interpreter, a network protocol, a graphics toolkit, a Javascript framework.
That will already propel you into the 95-99 % quantile in terms of technical understanding. I see e.g. so many frontend people that only have a superficial understanding of how Javascript or a browser works, or how to write good CSS from scratch.
To become great, look what's underneath each abstraction and see how many layers down you can go and still understand stuff. Try to build your own abstractions from the ground up, e.g. write an ORM, write an interpreter, a network protocol, a graphics toolkit, a Javascript framework.
That will already propel you into the 95-99 % quantile in terms of technical understanding. I see e.g. so many frontend people that only have a superficial understanding of how Javascript or a browser works, or how to write good CSS from scratch.
This is my perspective as well. Be able to apply, or write an appropriate tool for a job, and recognize a given tool's suitability for a task. This means, you don't identify yourself as a "python programmer", "react programmer" etc, but are able to evaluate a range of tools. And, understand how the tools work, and know how to build one. This likely will involve some low-level (think register-level) code. Or for web stuff, being comfortable with network architecture and web standards.
Another way of phrasing it: Being a general, cross-domain programmer, vice a provincial one. Being able to recognize when a best-practice or dogma in a given domain isn't applicable, because you are familiar with multiple sets of these practices, and therefor recognize their mutual inconsistency.
Another way of phrasing it: Being a general, cross-domain programmer, vice a provincial one. Being able to recognize when a best-practice or dogma in a given domain isn't applicable, because you are familiar with multiple sets of these practices, and therefor recognize their mutual inconsistency.
But does that make you great? I think my point of becoming “great” (idk if that ever happened, but I ticked all your boxes) was when I stopped inventing piles of abstractions and started just writing TFC. /\ type of curve.
The best (imo) programmers I’ve met IRL were pragmatic niche dudes and gals and they loved their job and never expressed developer anxiety. Otoh, our generic kind… honestly not sure if it was worth it.
The best (imo) programmers I’ve met IRL were pragmatic niche dudes and gals and they loved their job and never expressed developer anxiety. Otoh, our generic kind… honestly not sure if it was worth it.
> The best (imo) programmers I’ve met IRL were pragmatic niche dudes and gals and they loved their job and never expressed developer anxiety
You get there by understanding what you are doing, uncertainty leads to anxiety. And you get to that understanding by trying to invent a pile of abstractions so you understand how those works and when to use them and when to not use them. You can't just skip that learning phase and go direct to expert.
You get there by understanding what you are doing, uncertainty leads to anxiety. And you get to that understanding by trying to invent a pile of abstractions so you understand how those works and when to use them and when to not use them. You can't just skip that learning phase and go direct to expert.
Absolutely this, ditching MonoGame for my videogame pet project and instead building my own (micro-)engine from scratch taught me so much.
I think I became a significantly better programmer when I began to understand the value of programming from the perspective of others in a business. I still run into engineers who are technically stronger than me - why wouldn't I? There's finite time in the world and infinite depth to study. It seems a lot of engineers have a penchant for going deeper and deeper and, from my perspective, it can result in a desire to overengineer solutions. It's fun and interesting to play to one's strengths and, as the technical expert in the room, others have to listen to your guidance. If you say the technical thing needs to be built then it's hard to argue against it.
But... I dunno. It's possible I am just getting lazier as I get older, but I've found that improving my communication skills, helping stakeholders understand the costs of what they're asking, verifying the value that expected cost is expected to generate, and getting alignment on delivering 80% of the solution with 50% of the effort is what others truly value and reward.
That said, it likely depends on your domain, too. The technical difficulty of engineering jobs likely varies wildly between fields.
Anyway, to answer the question more directly, I became a better developer when I became passionate about a project I had a vested interest in seeing succeed. Only then did I find the motivation to research problems to the depth necessary to have "ah hah!" moments. I found myself in this position by working on a personal project until it became popular. The popularity then fueled my desire for increased status, I poured myself deeply into the project, and levelled up my technical abilities significantly as a result. Once I had that experience, though, it seemed like there was diminishing returns on difficulty/knowledge acquisition, as you seem to be noting, so I focused on becoming a more well-rounded technical person rather than pursuing depth.
But... I dunno. It's possible I am just getting lazier as I get older, but I've found that improving my communication skills, helping stakeholders understand the costs of what they're asking, verifying the value that expected cost is expected to generate, and getting alignment on delivering 80% of the solution with 50% of the effort is what others truly value and reward.
That said, it likely depends on your domain, too. The technical difficulty of engineering jobs likely varies wildly between fields.
Anyway, to answer the question more directly, I became a better developer when I became passionate about a project I had a vested interest in seeing succeed. Only then did I find the motivation to research problems to the depth necessary to have "ah hah!" moments. I found myself in this position by working on a personal project until it became popular. The popularity then fueled my desire for increased status, I poured myself deeply into the project, and levelled up my technical abilities significantly as a result. Once I had that experience, though, it seemed like there was diminishing returns on difficulty/knowledge acquisition, as you seem to be noting, so I focused on becoming a more well-rounded technical person rather than pursuing depth.
For me, the biggest leaps were caused by exposures to new languages/paradigms.
I recently commented about that here:
> For me, leaving a plateau usually requires a paradigm shift. Here's a few rabbit-holes for you:
> • Learn memory management from Rust
> • Study Postgres internals: https://www.interdb.jp/pg/
> • Learn architecture and design from Elm: https://taylor.town/elm-2023
> • Try building things "from scratch" with zero dependencies
> • Watch online lectures from Joe Armstrong, Alan Kay, Gerald Sussman, Bret Victor, Casey Muratori, Greg Young, Richard Feldman
> • Build a robot
> • Learn a semi-esoteric language like Forth, APL/J/K/BQN, Lisp/Scheme, Wolfram Language, etc.
> But research isn't enough. I never really understood the value of new paradigms until I tried to use them in a personal (or professional) project.
[1] https://news.ycombinator.com/item?id=39580801
I recently commented about that here:
> For me, leaving a plateau usually requires a paradigm shift. Here's a few rabbit-holes for you:
> • Learn memory management from Rust
> • Study Postgres internals: https://www.interdb.jp/pg/
> • Learn architecture and design from Elm: https://taylor.town/elm-2023
> • Try building things "from scratch" with zero dependencies
> • Watch online lectures from Joe Armstrong, Alan Kay, Gerald Sussman, Bret Victor, Casey Muratori, Greg Young, Richard Feldman
> • Build a robot
> • Learn a semi-esoteric language like Forth, APL/J/K/BQN, Lisp/Scheme, Wolfram Language, etc.
> But research isn't enough. I never really understood the value of new paradigms until I tried to use them in a personal (or professional) project.
[1] https://news.ycombinator.com/item?id=39580801
The good/great line is something you can stumble over and and then fall back from because it's a relative measure that has a zigzag to it, exactly the same as how artists perceive their work vs others. At first you know with some confidence that you're bad, and then you pick up a few tricks and get a swollen head for a while, until one day you notice some great feat that you knew nothing about. Then you are back to being an imposter knowing nothing again.
That repeats over and over, it just becomes more nuanced and specific in some ways and more general in others. You have "good days" and bad ones, and you're often exposed to the really different ideas simply by being "in the room" to engage with them properly on a project instead of skimming over someone's half-assed summary.
The two interesting areas of programming, to me, are at the very bottom of the stack near the hardware, and the very top where there's intensive abstraction and algorithm design. The parts in the middle are quicksand; it's pragmatically useful and productive for a job to know some little corner of C++ or a certain Unix tool or a longstanding bug in a Javascript framework. But that's not "programming" in the broad sense either. Shuffling around stacks of dependencies that have been vendored out for your consumption isn't the good part, and ultimately leads towards becoming what James Hague calls the "recovering programmer":
https://prog21.dadgum.com/56.html
Part of the bitterness he speaks of comes from the feeling of perpetual consumption: if you're always learning a next "new thing" you never feel like you've built much of your own. So you have to decide for yourself a cut-off line where you will start to DIY more of it, where you won't do things the "standard" way or aim to have a large, publicly visible project or other such demons in your head. At that point you can just program.
That repeats over and over, it just becomes more nuanced and specific in some ways and more general in others. You have "good days" and bad ones, and you're often exposed to the really different ideas simply by being "in the room" to engage with them properly on a project instead of skimming over someone's half-assed summary.
The two interesting areas of programming, to me, are at the very bottom of the stack near the hardware, and the very top where there's intensive abstraction and algorithm design. The parts in the middle are quicksand; it's pragmatically useful and productive for a job to know some little corner of C++ or a certain Unix tool or a longstanding bug in a Javascript framework. But that's not "programming" in the broad sense either. Shuffling around stacks of dependencies that have been vendored out for your consumption isn't the good part, and ultimately leads towards becoming what James Hague calls the "recovering programmer":
https://prog21.dadgum.com/56.html
Part of the bitterness he speaks of comes from the feeling of perpetual consumption: if you're always learning a next "new thing" you never feel like you've built much of your own. So you have to decide for yourself a cut-off line where you will start to DIY more of it, where you won't do things the "standard" way or aim to have a large, publicly visible project or other such demons in your head. At that point you can just program.
I don't call myself a great programmer, even after 40+ years as a professional programmer. Whether my projects succeed or fail depends on a lot more than my own skills.
I think I have a set of talents that make me good at methodically solving problems. I have natural curiosity. I like learning on my own and from other people. I self-taught, read everything I could find (back in the '70s and early '80s), practiced a lot, started at age 14. I got lucky with some good mentors early on, that made a big difference. My grandparents bought a terminal and modem for me when I was 16 so I could spend more time programming. I had some great jobs that let me work with people with more and different experience.
I think a lot of luck and circumstance goes into success, but you also need hard work and probably an innate inclination to put in the extra work. Everyone I have ever known who succeeded, in any field, put in a lot of work, but they also had talents and traits that made success easier or more likely.
I don't think in terms of getting "great" at programming. I think in terms of solving business problems and adding value for my employer or customer. What does it even mean to call someone a "great" programmer?
If I have to give advice I'll say read a lot of code, learn from your peers, especially those more experienced than you. A good mentor or two can make a huge difference.
I think I have a set of talents that make me good at methodically solving problems. I have natural curiosity. I like learning on my own and from other people. I self-taught, read everything I could find (back in the '70s and early '80s), practiced a lot, started at age 14. I got lucky with some good mentors early on, that made a big difference. My grandparents bought a terminal and modem for me when I was 16 so I could spend more time programming. I had some great jobs that let me work with people with more and different experience.
I think a lot of luck and circumstance goes into success, but you also need hard work and probably an innate inclination to put in the extra work. Everyone I have ever known who succeeded, in any field, put in a lot of work, but they also had talents and traits that made success easier or more likely.
I don't think in terms of getting "great" at programming. I think in terms of solving business problems and adding value for my employer or customer. What does it even mean to call someone a "great" programmer?
If I have to give advice I'll say read a lot of code, learn from your peers, especially those more experienced than you. A good mentor or two can make a huge difference.
1. Realising that 99% of the time, the stack doesn't matter. Users don't care about whether you're using a single PHP file or a dozen NodeJS microservices.
2. Realising that complexity is the enemy. Smart people avoid complexity, dumb people who think they're smart introduce complexity.
3. Realising that in order to ship anything worthwhile you need good specifications, a clear line in the sand, and the time to be left alone to do it.
Edit:
4. Shipping something small is good. You don't know what is needed, but once you've ran something in production for a few days you probably will. YAGNI and MVP all the way!
2. Realising that complexity is the enemy. Smart people avoid complexity, dumb people who think they're smart introduce complexity.
3. Realising that in order to ship anything worthwhile you need good specifications, a clear line in the sand, and the time to be left alone to do it.
Edit:
4. Shipping something small is good. You don't know what is needed, but once you've ran something in production for a few days you probably will. YAGNI and MVP all the way!
Understand your Environment deeply, not only the basics (Version Control, IDE, Tools)
Don't avoid annoying things - try to be the one who can solve anything
Learn how to automate repetitive tasks quickly (e.g. shell scripting + tools)
Understand deployment and devops
Write documentation together with the users for better requirements understanding
Keep up with modern tech (e.g. ChatGPT, Phind, CoPilot, etc.)
Learn concepts, not Frameworks[1]
1: https://pilabor.com/blog/2021/05/learn-concepts-not-framewor...
Don't avoid annoying things - try to be the one who can solve anything
Learn how to automate repetitive tasks quickly (e.g. shell scripting + tools)
Understand deployment and devops
Write documentation together with the users for better requirements understanding
Keep up with modern tech (e.g. ChatGPT, Phind, CoPilot, etc.)
Learn concepts, not Frameworks[1]
1: https://pilabor.com/blog/2021/05/learn-concepts-not-framewor...
Programming in and of itself is just assembly -- dig the foundation, pour the concrete, frame the building, run the utilities, hang the drywall. There is significant art and craft in assembly, but it's a means to an end, and the craft is rarely appreciated by the untrained eye.
Programmers often get to design AND assemble simultaneously, because you can't put together something that hasn't yet been conceived -- and design is where most of the perceived value lies to the non-programmer. The final product looks nice, it feels nice, it does something amazing that I want or need it to do. WHOEVER MADE THIS IS A GENIUS! STEVE JOBS INVENTED THE IPOD! HE WAS A GREAT PROGRAMMER! etc etc. The perception of greatness overshadows the many half-truths and un-truths in the myth.
Beware lionizing "greatness" as the ultimate goal -- society tends to designate it as a shallow summary of a big thing (big number, big building, big company, big media coverage, etc). Sometimes greatness is also bestowed upon things in hindsight, after the grimy details surrounding the thing have been long forgotten or eroded into a tidy, bite-sized story.
If you're bored / hit a wall learning and applying things other people have invented, you'll need to invent some things of your own to recapture that dopamine rush that was there at the beginning. If you have nothing to invent, as others have mentioned in the comments, the next fulfilling challenge will be learning to provide quality service to others as a programmer -- to businesses, as part of a team, etc. Get paid to help them achieve their goals. Guide them through the bog that is modern technology. Provide value in quality implementation and insightful counsel, help them win their biggest wins and you'll become invaluable. In their eyes you will be great, and your reputation will start to precede you.
Programmers often get to design AND assemble simultaneously, because you can't put together something that hasn't yet been conceived -- and design is where most of the perceived value lies to the non-programmer. The final product looks nice, it feels nice, it does something amazing that I want or need it to do. WHOEVER MADE THIS IS A GENIUS! STEVE JOBS INVENTED THE IPOD! HE WAS A GREAT PROGRAMMER! etc etc. The perception of greatness overshadows the many half-truths and un-truths in the myth.
Beware lionizing "greatness" as the ultimate goal -- society tends to designate it as a shallow summary of a big thing (big number, big building, big company, big media coverage, etc). Sometimes greatness is also bestowed upon things in hindsight, after the grimy details surrounding the thing have been long forgotten or eroded into a tidy, bite-sized story.
If you're bored / hit a wall learning and applying things other people have invented, you'll need to invent some things of your own to recapture that dopamine rush that was there at the beginning. If you have nothing to invent, as others have mentioned in the comments, the next fulfilling challenge will be learning to provide quality service to others as a programmer -- to businesses, as part of a team, etc. Get paid to help them achieve their goals. Guide them through the bog that is modern technology. Provide value in quality implementation and insightful counsel, help them win their biggest wins and you'll become invaluable. In their eyes you will be great, and your reputation will start to precede you.
I think you'll get two kinds of people answering: those who overestimate how great they are, and those who underestimate how much of their greatness is due to natural ability.
Just like no amount of weightlifting will turn me into Eddie Hall and no amount of studying will turn me into Albert Einstein, no amount of programming will turn me into John Carmack. I've learned to make peace with that.
Just like no amount of weightlifting will turn me into Eddie Hall and no amount of studying will turn me into Albert Einstein, no amount of programming will turn me into John Carmack. I've learned to make peace with that.
I guess I tend to lean towards the growth mindset here. In my personal view and it may just be my own naivety. I do feel general intelligence or in this specific case programming capability can be developed to any level through sheer work and dedication. Not to fall into the first group of people you describe though I feel more of the world's John Carmacks are created through an almost unnatural obsession with failure and the confidence to push forward, rather than being naturally gifted or accustomed to success coming easily to them.
That's what self-help books would like you to believe, yes. But (assuming you are average size) you can always go down to a local bar and pick a fight with a guy twice your size for a reality check. The same principle also applies to brains.
My reply comment to "confidantlake" is meant to address this statement as well.
I don't think there is any evidence for this belief.
Well there are general studies and cases to support this -- example: Blackwell, L. S., Trzesniewski, K. H., & Dweck, C. S. (2007). Implicit theories of intelligence predict achievement across an adolescent transition: A longitudinal study and an intervention.
Though I anticipate this is not really what you are drawing at here.
While I can definitely agree that inherent talents or traits may put an individual ahead of others. I just dont see the scenario where talent beats hard work. Now dont get me wrong Im not trying to imply that a turtle can train to outrun a cheetah, but rather that in the realm of intellectual pursuit, I believe the landscape is significantly more malleable. To me, asserting that talent or intelligence is fixed would imply that knowledge and understanding are also static. Yet our capacity to think, interpret, understand and extrapolate is ever evolving. So I still feel the growth mindset is more closer to the "truth" in the sense that novel thinking and innovation can expand intelligence. Im not looking to deny the existence of innate capabilities but rather draw some emphasis to the potential of persistence and effort in learning.
Though I anticipate this is not really what you are drawing at here.
While I can definitely agree that inherent talents or traits may put an individual ahead of others. I just dont see the scenario where talent beats hard work. Now dont get me wrong Im not trying to imply that a turtle can train to outrun a cheetah, but rather that in the realm of intellectual pursuit, I believe the landscape is significantly more malleable. To me, asserting that talent or intelligence is fixed would imply that knowledge and understanding are also static. Yet our capacity to think, interpret, understand and extrapolate is ever evolving. So I still feel the growth mindset is more closer to the "truth" in the sense that novel thinking and innovation can expand intelligence. Im not looking to deny the existence of innate capabilities but rather draw some emphasis to the potential of persistence and effort in learning.
I kinda agree with you. I tried to make peace with myself too. So far it is not there yet but I'm making some progress.
I wouldn't qualify myself as a great programmer, but I never had the feeling of reaching a wall. There are just so many things to explore. I would just pick a language or area I'm not familiar with and try to work on some project.
Write a (mini)C compiler in OCaml. A distributed reliable key-value value store using the Raft protocol in Go. Work on some toy OS in C. A Gameboy emulator in Rust. A doom-like game in C++. Do 500 leetcode problems. It's endless!
I personally like to pick up some programming projects from MIT or similar institutions. Considering you're self taught, you may benefit from more academic material. Just pick something that corresponds to your level.
Write a (mini)C compiler in OCaml. A distributed reliable key-value value store using the Raft protocol in Go. Work on some toy OS in C. A Gameboy emulator in Rust. A doom-like game in C++. Do 500 leetcode problems. It's endless!
I personally like to pick up some programming projects from MIT or similar institutions. Considering you're self taught, you may benefit from more academic material. Just pick something that corresponds to your level.
Shift your focus: Instead of just building new things, try diving deeper into a specific concept that interests you within your current knowledge base. Maybe explore design patterns, algorithms, or a new framework within your existing language. You might be surprised how much more there is to learn.
Challenge yourself with a project that pushes your boundaries: Look for open-source projects you can contribute to, or brainstorm a personal project that requires you to learn new skills. This will expose you to different coding styles and approaches, accelerating your growth.
There are tools that can help with both approaches, but that's a topic for another day ;)
Challenge yourself with a project that pushes your boundaries: Look for open-source projects you can contribute to, or brainstorm a personal project that requires you to learn new skills. This will expose you to different coding styles and approaches, accelerating your growth.
There are tools that can help with both approaches, but that's a topic for another day ;)
If you wanted to go from good to great - electrician, plumber, bricklayer - what would you do?
It's not magic. Take yourself seriously as a tradesperson, continually read about the field, and work for companies that provide you with high quality experiences.
I don't know that I'd call myself a 'great' programmer, but I am quite a bit better than I was ten years ago. And the reason for that largely comes from using that ten years of experience to improve my understanding of the field.
There isn't a silver bullet beyond putting the work in.
It's not magic. Take yourself seriously as a tradesperson, continually read about the field, and work for companies that provide you with high quality experiences.
I don't know that I'd call myself a 'great' programmer, but I am quite a bit better than I was ten years ago. And the reason for that largely comes from using that ten years of experience to improve my understanding of the field.
There isn't a silver bullet beyond putting the work in.
Writing [0]
Knowing more that what's needed. You work with SQL? Learn other types of storage. Your main language is OOP? Learn other styles of languages. Be knowledgeable in other domains such as networking, OS, game dev, storage, how memory works, etc.
[0] https://www.yieldcode.blog/post/why-engineers-should-write/
Knowing more that what's needed. You work with SQL? Learn other types of storage. Your main language is OOP? Learn other styles of languages. Be knowledgeable in other domains such as networking, OS, game dev, storage, how memory works, etc.
[0] https://www.yieldcode.blog/post/why-engineers-should-write/
I wouldn't say I'm great, but the best ones I know have been excellent at understanding code just by reading it. Lots of stuff gets abstracted out from docs, often at the drivers level.
It's not just about knowing the framework, but where it breaks, where it shines, how it's meant to be used. Which part is being held together with duct tape? How is it processing a certain graphics type?
It's not just about knowing the framework, but where it breaks, where it shines, how it's meant to be used. Which part is being held together with duct tape? How is it processing a certain graphics type?
I leveled up a lot from working with engineers who are more senior than me, understanding different parts of the software development pipeline by working with DevOps engineers, and just approaching every next projects with a mindset of always finding a better way to accomplish the goal.
> I leveled up a lot from working with engineers who are more senior than me
I also benefitted a lot from this. For me, the difference was learning design, not just programming - what to build, not just how to build it. And learning some taste in design, some balance, where you don't overcomplicate or do something too simplistic.
That took a couple of decades...
I also benefitted a lot from this. For me, the difference was learning design, not just programming - what to build, not just how to build it. And learning some taste in design, some balance, where you don't overcomplicate or do something too simplistic.
That took a couple of decades...
If someone claims about himself being a great programmer — extremely high chances it's just an arrogant prick with ego inflated by high salary or working in an important project.
Few really amazing developers I've met in my life were either humble or too busy to brag about the size of their genitals...
Just saying.
Few really amazing developers I've met in my life were either humble or too busy to brag about the size of their genitals...
Just saying.
I too was self taught. For me it was the perfect opportunity to express my best vision ever. Unfortunately it was followed by years of mediocrity. But for one year my work was special. That is to say, for me it wasn't advancing skill. It was a vision of something no one else had done.
Do you have any thoughts on what made that one year special? Really with this question I am wondering if this was early on in your learning process? I think a lot of what is frustrating for me at this point, is realizing that a lot of the initial joy I got in learning was almost in a ignorance is bliss phase. Not knowing or even caring to understand best practices or reading/learning documentation. I think back to one of the most fun moments I had early on just being excited and happy I was able to follow a youtube video to create a simple turn based monster vs human game and actually getting it running. Im way past this as far a knowledge base, experience and capability now but am struggling to get that same feeling in new projects.
Also I'm wondering do you still program?
Also I'm wondering do you still program?
I have had a revelation about this question, or the kind of it: You just have to be blessed, or cursed with an unlimited amount of must-know.
Good programmers treat programming as an art. Great programmers treat it as food and water.
Good programmers treat programming as an art. Great programmers treat it as food and water.
Open Source helped me level up my programming skills. Being involved in the open can be cut-throat and bash your confidence, but if you learn from it - it will help you a lot
I think mandatory code reviews with picky peers.
I eventually started internalizing good practices instead of having to consciously work at it.
I needed people keeping me honest to get to that point.
I eventually started internalizing good practices instead of having to consciously work at it.
I needed people keeping me honest to get to that point.
Effective Engineer by Edmond Lau and Game Programming Patterns by Robert were great reads
Define great
e.g. writing code without consulting any docs or writing code that meets business requirements?
e.g. writing code without consulting any docs or writing code that meets business requirements?
I don't really have a true definition of great in this context, especially since it seems to require a comparison to others or adherence to someones criteria for achievement.
By "great" I really meant reaching a point you've surpassed a threshold you previously thought was your limit. Though I guess also trying to highlight concepts or ideas that, based on peoples personal experience made them feel distinguished from others.
Also was sorta curious to hear from those with the confidence to be attacked online for calling themselves some arbitrary level of skill("Great") felt got them to that point.
By "great" I really meant reaching a point you've surpassed a threshold you previously thought was your limit. Though I guess also trying to highlight concepts or ideas that, based on peoples personal experience made them feel distinguished from others.
Also was sorta curious to hear from those with the confidence to be attacked online for calling themselves some arbitrary level of skill("Great") felt got them to that point.
I think you’ll find with any skill you learn, early growth comes quickly, and then takes much more time/effort for smaller gains.
To feel like you’re taking big leaps each day after reaching a level of maturity you’d likely need to be learning new things, which you’d likely pick up quickly and feel like you’re making a lot of progress, but you’d be sacrificing depth for breadth, if you’re way of finding new things is picking up a new language each week or making the same type of projects which don’t introduce new concepts.
At some point you just need to start making things. Let people use those things and get feedback, they’ll let you know what your blind spots are. Even something as simple and thinking about designing for an end user instead of just yourself will make you think a lot differently about your program. The first thing I really did on my own was a collection of scripts to help me at work. They helped me, but couldn’t really help anyone else. Eventually I started thinking about others and it got a lot better. I made a GUI front end so people could consume it easier, made settings so it could be customized, figured out how to compile it to distribute it to them without dependencies, started actually handling errors, testing edge cases, and fixing little bugs that I would simply avoid running into when it was just me. The whole thing became much more robust. That project, and a couple others, led me out of the sys admin space and over to being a software engineer.
If know one can use, or wants to use, what you’re writing… what’s the point? Thinking about building for people really helped me out when I was getting started.
To feel like you’re taking big leaps each day after reaching a level of maturity you’d likely need to be learning new things, which you’d likely pick up quickly and feel like you’re making a lot of progress, but you’d be sacrificing depth for breadth, if you’re way of finding new things is picking up a new language each week or making the same type of projects which don’t introduce new concepts.
At some point you just need to start making things. Let people use those things and get feedback, they’ll let you know what your blind spots are. Even something as simple and thinking about designing for an end user instead of just yourself will make you think a lot differently about your program. The first thing I really did on my own was a collection of scripts to help me at work. They helped me, but couldn’t really help anyone else. Eventually I started thinking about others and it got a lot better. I made a GUI front end so people could consume it easier, made settings so it could be customized, figured out how to compile it to distribute it to them without dependencies, started actually handling errors, testing edge cases, and fixing little bugs that I would simply avoid running into when it was just me. The whole thing became much more robust. That project, and a couple others, led me out of the sys admin space and over to being a software engineer.
If know one can use, or wants to use, what you’re writing… what’s the point? Thinking about building for people really helped me out when I was getting started.
more and more programming. still not great. just good-ish.
In the beginning it was exciting because I was learning so much that was new and was able to apply it and see tangible results. Now Im at the peak of my programming abilities so far with my current knowledge in programming and ability to understand and apply concepts, though I no longer feel like Im getting better each day.
Im just wondering if others have had a similar experience and what concept, idea or project was able to get you past this wall?