I've found high level books written by experienced developers have really helped me. In the past I'd try to learn this or that shiny new thing but found little long term gain.
What's been your long term successes?
The above provides technical credibility, which is immensely helpful for organizational politics. People listen, and respect your opinion if you're capable and deliver. Learning how to communicate, lead, and navigate people is much easier once you're technically credible in this field.
- Switching jobs when things get boring or I feel like I am not growing in the ways that I want to be. It's eye opening to begin a new job and feel like a noob again.
- Building side projects. Reading and following tutorials are good and all, but there comes a point where you just gotta build something to really grow.
- Becoming part of a community, because it motivates me to learn and improve and also to try to share what I learn with others. I think this happens best at a small, local level. I don't get much out of attending the big conferences (other than it's usually fun).
- Having a blog, or just someplace to keep track of the interesting things you learn about. Can be a good marketing tool for yourself as well.
- Keeping a high level of communication going with your colleagues about what you're working on. I feel like this has earned me promotions.
I'm trying to do this, but the only jobs I can get are the ones that will very quickly put me back in that position.
Say you’re asked to build checkout flow for your e-commerce product. You need a shopping cart page, a shipping page, a billing page, a confirmation page, and flow out to stripe, and then a success page.
Start by creating a single page that just shows a product name, user name, address, billing address, etc, and then a button to “create”. Click it and it should call off to stripe with that dummy data, and then it display a success alert.
Now circle back and make the address and billing data input fields.
Now circle back and create a couple of dummy pages that you click through with the forms and a pre submit confirmation page.
Now go back and start to wire up a shopping cart page.
By creating a through line at the start, you can test everything you’re building end to end, so you can really hone in on the product experience and make sure it’s what it should be for your specific product. It also gives you more flexibility to give demos along the way, as well as release the product earlier in its maturing cycle. Maybe you won’t love the style and format, but it’ll be more than good enough to get into customers hands sooner in the process.
Then follow the other user's answer about getting something working end-to-end first and fleshing it out after that.
These two things alone have helped me prototype things from ideation to working, testable project with almost a 100% success rate (even if the idea ended up being bad, of course).
EDIT: Should expand on the "mercilessly" part. Even if you think you'll need a trivial, small abstraction five minutes from now, don't code it until it's blocking you. It seems extreme (well, it is part of the Extreme Programming principles) but it has granted me a 10x improvement in productivity as well as code quality after really committing to it.
Learning to keep it simple & methods for avoiding code duplication. I tend to find when learning a new language that avoiding duplication teaches me how to use the language properly.
And the book, The Pragmatic Programmer helped me to communicate better.
It takes time and requires a certain level of curiosity, but, at least for me, I think it pays off.
2. Avoiding OOP and composition early in my career. When you learn to focus first upon the goals of an application how things come together becomes a late triviality not worth serious consideration.
3. Know the foundations, standards, and intentions of your software environment. Hoping to bullshit your way past this with a tool is an artificial constraint that slows down delivery, limits creativity/capabilities, and severely retards performance.
I'm not sure I understand number 2. I'd love to hear more.
Here is an example of a real world utility item with lots of decoration: https://c2.staticflickr.com/4/3098/3142471026_1c8f659c46_b.j...
I would rather do other things then spend the time digging through decoration when debugging.
You get more effective by understanding their needs and why they are asking you for something.
Implementing a thing really gives you a much deeper understanding of the thing (and tangent things) even if you never use your implementation in real life.
I develop apps for a living and work solo (coding, design everything) and have taken up very large projects. One of the apps I built a few years ago was a full blown YouTube client app with a lot more features. The app is now no defunct because of YouTube not allowing background playback and several API restrictions but that app took me over a year to put together.
Another app was a sudoku app I built which took several iterations to design and built and improve. One of my most recent apps is a Hacker News client which I built the iOS version for about 3 years ago and am just now finishing the Android version of the app. The iOS one took a good 6 months of work to build and the android one has taken me just over 3 months.
I have been able to take over such large projects and crossed the finish line by being persistent. I work solo and from home and basically work every day of the week. Some days it's a lot of hours - 12-16 hours, other days it's maybe just half an hour of fiddling around. As long as I put in at least a few minutes everyday and able to fix a bug or add a small feature or make a small UI design fix, it's a good day. It doesn't have to always be major improvements. It can be as little as adding a new theme color.
I learnt this from my past experience in weight lifting. Being persistent everyday makes you achieve major goals over time. This can be applied in other areas of life too - like reading books, weight loss etc.
There was a recent post on "The unreasonable effectiveness of just showing up everyday":
2. Read other people's code. Reading others' code is a skill. Reading code is the best way to learn what's idiomatic in a language.
3. Focus on principles. Learn how they're applied in different settings. Don't spend time chasing the "new shiny" unless you have a need/reason.
4. Work on your people skills. After a certain point, telling computers how to behave becomes easy. But communicating with and inspiring people, learning how to amplify others' strengths, work around their weaknesses, and doing it all w/ humility and grace, while leaving others feeling positive about the interactions can be challenging. It takes practice.
5. Don't ignore feedback, especially the stuff that's hard to hear.
- Learning functional programming (and applying the above to that learning) made me a better programmer in the non functional languages that I still spend most of my time using.
- Reading books and technical articles as an ongoing thing over many years, little bits of knowledge and understanding really accumulate over time.
- I actually found that practicing coding interview style problems and using them as a motivator to better understand core computer science algorithms and data structures has improved my programming, I think for similar reasons as my first point above.
However, the only thing that has helped me improve my raw programming ability is reading and writing code. Especially when working on new or difficult tasks.
Sunk cost fallacy be damned, you often write the first one to figure how to correctly right the second one.
In a sense , when to move to a new position you have to prove yourself again, and it also keeps you from becoming complacent .
While doing these labs: http://csapp.cs.cmu.edu/3e/labs.html
Also a colleague made me watch this from Jack Diederich: https://www.youtube.com/watch?v=o9pEzgHorH0
In 2020, I wanted to learn about micro-services so I made a project to learn the basics of Docker and containerize a web app.
If I went back now to read the code, I'd have no idea what's going on. Fortunately, I made a detailed video explaining the workflow and I can always reference that if I want to pick up where I left off. It's also nice to see that nearly ~2k people found that video useful.
Whenever I learn a new technology/framework, I immediately make a short video about it, and I OFTEN come back to reference that video at later dates.
Editing: Da Vinci (more powerful than iMovie)
Screen capture: OBS (less resource intensive than QuickTime)
A different take, I moved from product development into Cybersecurity Application Security and it enhanced my entire mindset around application development and building products.
It brought things to top of mind while I code that were lesser on the totem pole when in AppDev. I do not mean secure coding and remediating vulnerabilities but more holistic around building a product; security requirements, patterns, practices, etc.
1) if possible, do a rotation in Cybersecurity; specifically Application Security. This somewhat depends on what AppSec does at your company.
2) If your company has a security champion program, check that out.
A couple examples:
Smaltalk - made me a better Java programmer and taught me a lot of history
Ruby - Rails experience helped me level up to a FAANG job in 2008
You think you understand something until you go to write about it for others. Nothing structures knowledge in your own mind like writing about it. Nothing fills in gaps in your knowledge than being forced to write about it. Writing helps actively think through problems, helps you explain to others technical concepts. It also helps us structure programs to be readable with a writers eye. Writing helps you build empathy for others that don’t share your knowledge by forcing you into their shoes.
I just worked on some code where variables were named "poop", "crap", and "shit". How is anybody, including the original developer, supposed to know what values those variables hold?
after a long time mostly working on back-end code. It forced me to grapple with threading, concurrency, and asynchrony every day (stay off the UI thread!); I learned more
- Never be afraid to discard code
- Try building the same thing in a new way
- Try building using the same way in a new place
Favoring pragmatism over dogmatism.
- Working at a cryptocurrency exchange for a few years. I learned a lot about databases and security.
- Starting my own business.
- Write a work log and a personal log every day with learning/decisions/problems
Also, I love Pluralsight videos to learn, but others prefer books.