Ask HN: How to learn best practices when you have no one to teach you?
I am currently working for a startup and am one of 3 developers. Most of my work revolves around building the API in Node + Express as well as some small projects with MongoDB. The other developers don't really assist me since they have their own projects to work on, and, honestly, they have less experience and knowledge than I do.
So my question is: What is the best way for me to go about learning best practices in API development, or using MongoDB, or even just being a better software developer in general?
208 comments
[ 5.7 ms ] story [ 248 ms ] thread2. Experience pain in the form of late, buggy software and angry clients.
3. Read books and work on side projects. (Martin Fowler’s were my favorite).
4. Repeat for 5-10 years with hopefully ever-decreasing amounts of 1 and 2.
You probably think I'm kidding...
You can rattle off quotes and documents all day, but this doesn't teach 1% as much as the direct pain of dealing with st on the job.
If you made the same mistake twice, then you were in trouble.
I guess I’d be worried about classifying. “Play” part of discovery might have multiple cases of (nearly) identical “mistakes”.
“Experience: that most brutal of teachers. But you learn, my God do you learn.”
How Developers Stop Learning: Rise of the Expert Beginner https://daedtech.com/how-developers-stop-learning-rise-of-th...
How Software Groups Rot: Legacy of the Expert Beginner https://daedtech.com/how-software-groups-rot-legacy-of-the-e...
My interpretation of that has always been something like "repeating the same actions over and over again, but never importing any new knowledge from outside" where "outside knowledge" means books, classes, blog posts, videos, meetups, etc. So you can "learn" to just keep doing the same thing incrementally better by just doing it the way way for 10 years, but to make significant changes, you need whole new models, thoughts, and ways of seeing things.
Now sometimes you may make a big leap purely off introspection, applying logic, empirical experimentation, etc., but that would - IMO - be an exception for most people.
The way I've learned is through books/talks, common sense (often things are clearly terrible for obvious reasons), people willing to take risks on giving me projects, and sweat/mistakes/learning how to focus on the right things through experience
I myself have never had a technical mentor. Never needed one. What I did need and have were mentors for the other 90% of being a successful professional (and people who built my self confidence up).
This, of course, coming from a person with burn marks :)
10K line UserManager classes “work”.
That’s how you get the “expert beginner”.
https://daedtech.com/how-developers-stop-learning-rise-of-th...
The only feedback you get as a sole developer are your compiler and errors in production. You would never know that it isn’t a good idea to write your own AcmeDatabaseManager or AcmeLogManager.
Reading. Plenty of books, blog posts, and forum posts point out that you shouldn't have "10 KLOC UserManager classes".
The thing is, one has to figure out how to integrate "book learning" AND real world experience, so that they're constantly synthesizing a newer, better understanding.
[1] I’ve noticed that in codebases of Apache Spark, Apache Oozie, Apache Cassandra, and Firefox.
Definitely. I mean, some of them probably have some objective basis. But clearly some of them are indeed subjective and arbitrary. Take "long method names" for example... I believe method names should state what they do, and should be however long it takes to do that. To my way of thinking, making a method name shorter just for the sake of being shorter, and eliding semantic information, is an anti-pattern, not a best-practice. shrug
Keep looking at it and ask if you are doing something redundantly.
The only feedback you get as a sole developer are your compiler and errors in production.
False. There's plenty of resources online. There's plenty of code to read online. There's plenty of potential critics online.
You would never know that it isn’t a good idea to write your own AcmeDatabaseManager or AcmeLogManager.
Unless you've read the Internet. There are plenty of database and log utilities out there.
Because it hurts.
With as many people as we have on Earth it is unlikely that one special unique problem can only be solved by one special unique person. While it might happen, it's unlikely to happen to a software developer at a small company. The problems and solutions you find there are often relatively comparable or even generic, and are found and solved by many people in parallel at the same time. While working together might be faster, it has nothing to do with the feasibility of detecting and repairing issues.
It's a good question, one that's a good nod towards the principle that you will inevitably learn more slowly if your own mind is the only one you have to work with (and lately I've been thinking about how I can get in a professional position where I'm near the bottom end of the intelligence and/or domain knowledge range in the room for this very reason).
But one answer might be: you'll know. "Works" is shorthand for satisfying a certain set of expected conditions. There's a core of reliable behavior in the software that's the minimal working definition of "works" ... but there's also the question of relative ease when it comes to reading, understanding, and changing/augmenting the code you have, or how the code "works" as an expression of the system for the purpose of presenting an interface to the developer.
Chances are pretty good you know the feeling of writing something that you either (a) are uncertain is really adequate as far as the developer experience goes or (b) you know is probably not adequate but seems to get you to the minimal definition of "works" fastest.
Listen to that feeling. Interrogate it. Try something different. Observe the tradeoffs.
If you get a production bug that takes a week to fix because the code is a mess you feel it. If adding simple new features is a pain, you feel it.
Now, of course, you might want to skip that, by learning from others, but OP is suggesting that you make your own mistakes.
By this time, that one inexperienced developer gets promoted to "Architect" because he knows where all of the bodies are buried. Now one of two things happens. He brings in more inexperienced developers because he doesn't know what a good developer is and they keep adding on to the UserManager class and to organize it better, they add section breaks. The class grows.
If they are lucky, they get an experienced developer who tries to tell the "Architect" about proper coding techniques, management and the architect dismisses the critique as "if it ain't broke don't fix it"/"this is the way we've always done it". All of the good developers leave and you are left with only bad developers.
Then you end up with the "Dead Sea Effect"....
http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...
If the 10k line UserManager class has you pulling your hair out, you know you have a problem.
It's all about hundreds of cost/benefit trade-offs in a particular context. There will be trade-offs between short, medium, and long term goals and issues. There will be trade-offs between the developers, management, sales, and the users. Try to find as many compromises as possible which are synergistic.
When it comes to hiring and otherwise interacting with other coders, you will even make compromises with the developer community!
4. Repeat for 5-10 years
At least. Always be learning from your mistakes. Be skeptical of yourself and your own model of reality. You should be actively looking for your biases and misunderstandings. Try to understand where the contrarians are coming from. If they have a point, it just might be valuable.
Be wary of dogmatism.
Strangely, there have been very few customers who have been unhappy. Many have even written long glowing reviews that have had a great positive impact in profits.
Those who give negative feedback seem to always have a problem or a pain. Being kind of a bloodhound to discover what that pain is and where did it come from seems very valuable.
Two most difficult things for me seem to be: A. drawing borders and limits on my time and what to do and when to say no, B. pricing
They say just surviving long enough mean you win, but turning a business to make profit seems really a herculean task, even as a solo dev.
Pragmatic Programmer: http://amzn.com/020161622X
Code Complete 2: http://amzn.com/0735619670
Design Patterns is also very well known https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...
The hard part is finding the right blog. There are a ton of blogs out there from developers with little experience who are convinced that their way of doing things is the best/only/right way. The blogs are often nothing more than SEO for their resumes.
For that reason, I'd lean heavier on books. At least with books there is some filter. Yes, it can be incomplete and sporadic, but it's often better than the wild west of bad information out there, especially in web dev blogs.
Emphasis on GitHub repos: you can learn a lot of good practices and efficient solutions in open source projects somewhat related to your problem domain.
Take Mongo for example: is the issue that your database keeps going down? If you frame it that way, it doesn't take long to discover clustering, replicasets, and monitoring. Is the issue that your queries are hammering the server? If so, googling that leads you down a months-long rabbit hole that ends in indexing, caching, and denormalizing strategies. Are you frustrated with the amount of boilerplate needed to get mongo data to the frontend? That's a good hint that you're in the market for a library/framework that might help with that.
Much in the same way that one of the hardest parts of solving a bug is knowing what to Google, specifically defining what "better" looks like is the first step towards getting there.
In most cases, the leverage you'll get from this, compared to trying to learn everything yourself, tends to be overwhelmingly greater than the cost of searching.
If there is no one to answer your questions in your company - try and find some buddies on the internets or even change company, as in my experience, ability to ask stupid questions and get answers quick is crucial in learning programming. StackOverflow is good, but not quick enough.
——-
Ouch, sorry, misunderstood your question. I am not sure there is a book on best practices on APIs, but it’s definitly possible to have someone experienced help you as a company. There are good developers with experience doing this type of contractor work.
——
If not, it pains me to know that there still isn’t an answer besides, “quit and be skilled enough at determining that a company is good at teaching best practices.”
> books
Are a way to absorb information that the author thought a broad audience would want to know and be able to digest. They don’t replace being able to get detailed individual feedback on your work and your particular questions.
> make mistakes
In my experience, mistakes have one big flaw: They don’t teach you a way to do something correctly. It is possible to go into a situation thinking, “I don’t know what to do here and I need help.” And to come out of the situation saying, “Yep, I did my best and I failed in pretty much the way I thought I would. New information learned: none.” Ideally, you would be able to shop for or come up with a workable solution yourself. In reality, humans benefit greatly by learning from the past solutions of others and from getting personal recommendations.
It's less that you'll learn best practices, but you will expose yourself to the zeitgeist, which I feel is important to being a good dev. Again, not to blindly follow it or even agree with it, but to understand it and why it's pushing in one direction or another.
If you work with people who are already experts, they will always prevent you from making mistakes. Being able to actually make those mistakes gives you a much better understanding of why people do things though.
It's when a Junior-Mid dev has to add a feature that's made difficult by their own choices and then rethink to make things better they tend to learn. That said, plenty of Jr-Mid devs don't advance with more practice, they stay jr-mid.
The term is flawed to start with in the sense that it invites you to think of practices as fixed or objective rather than contextual.
You should think of your development as striving to amass the experience/wisdom to recognize the practices that are likely to work better in each situation on the fly. And that just comes with hours and hours and hours of trying different stuff and seeing for yourself (consciously) what you like best and what works best and when. It's slower, but finding that stuff out through experience is really the only true way to learn. Knowledge is a commodity, wisdom is what matters.
And there's a lot more subjectivity to it than we normally treat it as. A given practice can be better along dimension X. But two (great) developers can disagree about whether X is the dimension to optimize vs. Y.
If what you need is a specific practice that is working for people in one specific context at one specific time, you can search the web. But even then, it's not a black and white "best" thing and without your own instinct to judge what you're reading or being told by someone, you're making at some level a guess.
You can try to learn on your own by reading, but if you want to make serious progeaa, you need a teacher, it's as simple as that.