5 ms·
For context I have been programming for 40 years, professionally for 30. In my experience programmers have to travel through 3 stages (not all get to stage 3).
by bruce511 5y ago
For context I have been programming for 40 years, professionally for 30.
In my experience programmers have to travel through 3 stages (not all get to stage 3).
1. You code to prove to yourself that you can
2. You code to prove to others that you can
3. You don't need to prove anything anymore, so now you code for utility (ie earning a living etc.) At this point the code is not the goal, the goal is something else -the code is a way to achieve that goal.
It's important to work through these steps - it's hard to jump to step 3 without "earning your chops" along the way. Those foundations are what make step 3 effective.
I say this for you to set the context of where you are at. You are not your code. your code is not perfect. You will always look back on "old" code (like from 6 months ago) and feel you can do better. That's called growth and it's a good thing. If you look back and your code from 5 years ago is "perfect" then either you're not growing, or you've peaked :)
Interestingly I also say this so you can understand what "level 3" feedback you'll get. Mostly people don't care about your code, they care about utility. So in that sense you can expect utility-based feedback, not code-based feedback. It may be hard to hear about something you've worked so hard on, but for most of us the "code" is not the goal - utility is. It's like looking at the Mona Lisa, the painting is great, but I really don't care how many nights you spent painting it. Which can be tough to hear based on your doubtless effort and hard work.
So skipping over the code part, you've presumably got some project that's offering some utility. You want to build an audience for that utility. Welcome to your next job. Turns out "build it and they will come" is a myth. "Selling" something to an audience is staggeringly hard. Ironically even more so when said offering is free. Ideally you have the audience before the product, but that's not how experience works.
So, hopefully you can determine what kind of person would use your project. then you hang out where they hang out. You help them as much as you can. You build a reputation for helping them. You point to your project when it's truly the best fit. It takes time, and effort, to build reputation in this way. And along the way you try and keep the product itself as something people want to use, something they latch onto.
So yeah, keep your expectations low, then drop them some more. It's a tough place to get started in, and I can predict that you'll almost certainly fail. But in failure you can learn, and that's important. The thing I'd say you might learn is that you need to build an audience before you build the tool. That's what I learned. But your experience will be your experience.
I say all this not to discourage you, but to encourage you. You are on a journey, and you are seeing others already at their destination. That didn't happen overnight, and they likely walked a very hard road to get to where they are. Try and get satisfaction along the road - figure out what worked, and where you went wrong. Learn as much as you can from failure. Then do it all again :)
Good Luck!
- rjh29 5y agoOn what basis did you form that theory? I picked up programming as a child and have never wondered if I can do it, or cared if others knew I could do it, I have always been in step 3 programming to solve problems. There must be a lot of other people like me. If anything I've regressed to step 1 20 years later after burnout, but that's another story :P
- exikyut 5y agoTentative thought experiment / question: similarly to how some people absolutely fly through curricular study and then crumble once they enter the non-perfectly-spherical non-vacuum-based real world, maybe you simply never had any significant/blocking issues with learning and integrating programming into practical settings (perhaps due to chance opportunity, IQ or other factors) until recently? Maybe it was a breeze until now, and everything's caught up after burnout...?
- rjh29 5y agoThanks for your insight. I think I've always enjoyed programming until I didn't. So pushing through work even when I'm highly unmotivated has been pretty tough and definitely a new skillset to learn!
- bruce511 5y ago>> On what basis did you form that theory? I've had the pleasure to work with a large number of programmers from different companies, backgrounds and training over a long period of time. I've seen this pattern repeated over and over, although as I say some people seem trapped in stage 1 or 2. This is especially true for those who would rather spend a month coding something than spend $99 on a library to do the job. Conversely I saw a _lot_ of developers who saw only the end-goal (which typically meant getting paid) and would happily use whatever code they could get to get them to that goal quicker. I noticed that the ones who lived better, got paid more, were the ones that shipped, not the ones with "perfect code". [1] >> I picked up programming as a child and have never wondered if I can do it, or cared if others knew I could do it, I have always been in step 3 programming to solve problems. I too started young, and was self taught. I got through stage 1 pretty quickly, long before I'd even considered a career in this space. but certainly in the early days I was recreating things (games mostly) that were available at the time. During University days I was lucky to rub shoulders with some very skilled others, and we constantly pushed each other to get better, be better, show something off, and so on. I went in there "knowing everything" and only by interacting with others did I find out that "all I could do was program." I didn't necessarily see it at the time, but the formal education part (the "science" part) really helped me along my career. In my early work days I needed to prove my worth, demonstrate skills and so on. Once I was past that I became more productive - getting tasks done, not obsessing over every little naming detail. Build, release, iterate, perfect. Not build, perfect, perfect, iterate, never-release... I would suggest (with no data obviously) that you went through stages 1 and 2 early, and perhaps quickly. >> If anything I've regressed to step 1 20 years later after burnout, but that's another story Perhaps it's burnout, or perhaps it's reflective of the limits you reached. As I learned new languages or moved into new spaces, I tended to repeat the stages, so perhaps you're just regrouping. I think we're always learning sometime new (hopefully) so sometimes it can feel like regression. [1] Please don't read what I'm not saying here. Of course code matters, and like many I strive to produce the best code I can. But there's a balance. I use OpenSSL because despite the "ugliness" of some of that code, it's solid and it works, and I don't have time or energy to write something like that myself. I'm not advocating for using any old rubbish, I'm saying that quality libraries exist, and using them can often move a project quickly forward.