ps. using the youtube 2x playback speed option can really help digest lots of video content quickly [3]. I use this almost exclusively on youtube now.

[1] NodeConfEU 2018 - https://www.youtube.com/watch?v=UMgMSb7d-Os&list=PL0CdgOSSGl...

[2] MongoDB - https://www.youtube.com/user/MongoDB/videos

[3] https://sysadmincasts.com/episodes/52-video-playback-speed

Two things:

1) Sometimes it can be hard to find good YT vids, especially a series of vids that will deep dive into the topic you care about. Maybe sign up for an online course where there videos of the instructor coding in real-time and address things in detail.

That will definitely give you a place to start with someone who has actually professionally done things you’re doing according to some best practice.

2) After you’ve got an idea of what you think is best practice, even if you have lots of questions remaining, just keep moving ahead with your project with a focus on making sure your API successfully does what you plan for it to do.

it’s not possible for you to know all the best practices, especially in isolation, and still be productive. you have to get your work done, and some of it is just going to be terrible. It’s possible that you may end up with a lot of tech debt that requires time to go back over it to refactor, but what does your boss expect if you’re alone and making the whole thing by yourself?

Unfortunately, you have to meet your timelines, so compromises must inevitably be made. More could be said about this, but i’ll leave it there.

Also, overtime, you will start to see what the better way to implement things are, as you continue building out features and run into use-cases you might not have thought of previously. The videos and documentation you read later on will make more sense since you have a framework in your mind of how the patterns get used or implemented in code.

https://www.infoq.com/ is my favorite because they get talks from some of the most experienced software dev folks, and they cover almost every topic of software engineering

Firefox: https://addons.mozilla.org/en-US/firefox/addon/videospeed/

Chrome: https://chrome.google.com/webstore/detail/video-speed-contro...

I watch all my videos at 2x speed now and I was shocked how much time I saved. It no longer takes me most of the night to work through my YouTube notifications, and has left me so much more time for project work during the week.

Firefox: https://addons.mozilla.org/en-US/firefox/addon/enhancer-for-...

Because there are other options like switching off one tab when you start video in another tab, overlay if you scroll down, default quality (I have to be on 144p because of bandwidth constraints)

You can go up to 16x speed and turn on captions to speed-read through

Really just depends on how much content the video has

example write in console: $('video').playbackRate = 3; (and playback rate would be 3x) Works with rates between 0.0625 - 16.0(tested in Chrome and FF).

For example, I worked at Intel, Lucent, Apple and DEC. Each one had significantly different "best practices". When I look at how we did code there vs something like, oh, the GNU project, they were WORLDS apart. So even if you made the claim, you'd still fall short from the new environment.

If you're lucky, eventually YOU'LL be the one defining best practices.

Just learn how to write idiomatic code in whatever language / framework you are using. At least the approaches are good enough. And other OCD/Autistic programmers won't lose their shit when they see it.

Do try to write code in an active AKA explicit way. Whne you read the code it should be obvious what it's trying to do. Code where the right thing 'just happens' is never clever it's just bad.

Do remember the process you use for a tiny team is different than google or facebook or a web dev sweatshop.

However, "idomatic" means writing in a way that other people are likely to be able to understand. That's a great goal! Often it's worth it to write code that isn't quite as good for the situation if it is more idiomatic. It's a judgement call still, but it's still important to know what is and isn't idiomatic so that you can make that judgement call.

Idiomatic is more neutral and means basically just do it the way everyone else tends to. The real advantage to that is you generally avoid pitfalls and annoying other coders.

How to learn idioms when you have no one to teach you?

Reading articles and books will teach you things that sound good but may not hold up in real life. Code is battle tested and real. To learn about art, you can read volumes about form, shape, color, composition etc. but you really need to look at great art. Same with code.

Of course, you may wonder "how do I find good code?" I would just try to find high-profile OSS that deals with whatever kind of tech you are interested in. It may not all be good, but if you diversify the code bases you read, you will notice the differences and learn for yourself why some might be better than others.

———

I’d like you to take as given that I’m reasonably intelligent — I graduated from MIT and have been working as a software engineer for 6 years. Yet when I sit down to read https://github.com/cypress-io/cypress or https://github.com/webpack/webpack, I don’t know where to start or how to incrementally build up an understanding.

How can I learn how to read a project’s worth of code?

https://www.dropbox.com/s/q5mtxxk6bswkag6/Read%20Code.pdf?dl...

https://www.nemil.com/on-software-engineering/index.html

(The article has a few great HN threads on reading code; after all, there are lots of contexts where you need to read without working someone in person who’s been involved in that code)

It is also important to have a clear goal. Let's say you want to understand how webpack starts up, or how it does a specific feature. Make this question your main concern and don't wander around. Don't try to understand everything at once. Divide and conquer.

It is also useful if you can ask questions, but please spend some time coming up with a theory first why things are the way they are. Formulate a hypothesis (e.g. "this piece is necessary because it handles an edge case", or "this piece of code looks uglier than the rest, is there a reason?") and try to prove it. If you can engage with the community, the better, but please don't outsource your "thinking efforts" to other project members. You can't learn how to reason about code, if you don't reason.

The most important one: be humble. Just because you would've solved a problem differently, it doesn't mean that the code is bad. Don't spend time judging the code. You are there to learn from others, so be open to other solutions. Whether it is a good or bad example is so difficult to judge... be patient and you will realise what kind of code is easy to understand. Once you have some idea, take that knowledge to your next project. This may take weeks/months/years depending on the project size.

I have found paper and pencil to work best for my brain trying to manage attention while doing many tasks, so I take this to heart. That said, I think there is probably a tool I can use to be significantly more effective in organizing my thoughts—but probably one made of paper and pencil in the genre of the bullet journal.

If anyone knows of any techniques of organizing notes like this, I’d be grateful for some names that I can google. For now, I’m going to try experimenting with various ways of using flashcards (ALA record cards).

(1) applying the "analytical reading" rules defined in "How to Read A Book" to a code base. One of those rules, as Olikas said, is formulating hypotheses and questions and "actively engaging" with a code base (or any text).

(2) Compare and contrast a similar project (i.e. using the same language and framework) to figure out whether the structure of the project in question is following a general layout or not (e.g. Maven projects in Java).

I’d seen that book a while ago but not picked it up. I’m now going to. Thanks!

> formulating hypotheses and questions

I think this reduces to “how do you keep those hypotheses organized?” which sounds kinda like the problem of “How do I write an outline?”

> Compare and contrast a similar project

This makes sense to me for web apps. Less so for a package manager.

I suppose that means the questions splits off into lots of domain-specific quesions like, “what should I pay attention to when reading a RESTful service?” “What should I pay attention to when reading a package manager?” Etc.

————

For a RESTful service, I would recommend first getting and idea of the core models from the API docs and then from reading structure.sql or models.py or whatever holds the relationships among tables. Draw an entity-relationship diagram on a big piece of paper of the important models.

Then, try and trace the path of a web request from the outside in through middlewares to the controller then to rendering and back out again.

For me, I just try to follow the data and logic flow from beginning to where I want to do things. Though if I see something like a "strategy" pattern I ignore it unless I really need to know how it works; same goes for other code branches that seem unimportant to the greater program. You absolutely should use something like an IDE where you can move around quickly and get neat features like jumping to a class definition, find usages, etc. in case you get lost. It definitely takes time and isn't something you can just sit down and do for 8 hours straight. I generally can only look at code for 90 minutes before my eyes start glazing over and I need to take a break.

It'll soon become obvious which ones are good codebases and which ones aren't.

* Switch job to a place where you can be pushed and mentored

* Make a lot of mistakes, but be sure to learn from them

* There are so many amazing books where the authors shared their mistakes/experience and how they made things better

* It's often much better to slow down and get things right by researching, discussing and prototyping than rushing and having to rebuild it a few times or maintaining shitty code.

* Try to think of the 10X when working on something. Of course, optimize for the current spec, but what happens if you get 10X more loads/users? Is there a way you can make it work for that use-case with roughly the same time? Often, the answer is yes by using a well-tested library and better tools. Ironically, sometimes being forced to think at a bigger scale makes you realize that your solution wasn't that great after all.. and that this problem was already solved.

I can't speak for other languages and frameworks but I know with Android Development it's useful to keep an eye on the subreddit (https://www.reddit.com/r/androiddev/) to see what the latest general consensus is with libraries and frameworks. There's also a #android-dev channel on Freenode IRC that I dip into from time to time. Meetups are pretty good too, and people tend to enjoy conferences although personally with my poor attention span I tend to switch off. There's a weekly newsletter as well which I find really useful (https://androidweekly.net/).

No idea what the equivalents would be for Node + Express and MongoDB but I'm sure they exist :).

GitHub, up for grabs issues. If you really want to learn, stick with the more popular proects, as they usually have more experienced developers involved.

The problem with this is that you need to work after-hours, which is not everyone's cup of tea.

If you want that (which is reasonable because it's an excellent almost invaluable resource for your career), you have to first find an organization that provides that. Where you're at may or may not be that place.

If you're a solo developer, stick to _standards_. There are standards for how something should be implemented (like REST), there are standards to how things should be written (like PEP8 for Python), etc.

Follow those standards as close as you possibly can. Ultimately, you'll find issues with them -- that's great! Perhaps you'll even find a more clear way of doing something that the standard doesn't suggest. This means you can probably iterate on your original design.

Join a Slack/Discord/IRC with other developers using your toolchain and ask questions there if you have concerns. If you're worried about design decisions, find others who have been in similar boats and ask how they did things and what the result was like.

Typically, best practices are those that emphasize 1) clear code, 2) readable code, and 3) the KISS principle. Anything that favors complexity over simplicity _must_ have a good reason for doing so.

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.

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.

Some years after I got into a company where everyone was much more experienced, and with mentors and all that. You know what? I become a mentor to most of them in a matter of months... Don't know how it happened, but it turned out that I've proven more agile.

Now I'm in a much more experienced and serious company, and now I do have seniors than myself. That helps a bit by helping me differentiate valuable from invaluable knowledge. But again, if you don't push yourself, no body will instead of you.

I'm not that experienced, it was only 6 years since I graduated.

=> technological bias

As you are from Node/Express and Mongodb background the biggest risk is trying to become only better in these technologies. So you will only know how to make faster horses, how to train them for the best, but you will never learn car exists.

More than best practices, what makes a great developer valuable (especially in a position like you where other people in your company are less experienced than you) is your ability to see wider not deeper.

Try to challenge the status quo ? Why MongoDB? What kind of alternative do you have ? Same for Node + Express.

Doing so will force you to see where your tool shine and where it reach its limit. Doing so will permit you to know when you need to dig deeper on "how to use better this tool", and when to step back and "wait a minute, no amount of best-practices/knowledge will balance the fact that MongoDB is just no the right tool here"

So read a lot, but also from people that are not from your community (and to be honest HN is a good starter on getting different point of view)

The other important things is about perspective, it's not because a googler/guy from netflix wrote about how they needed to split the code in microservices, or needed to implement $design-pattern-with-a-very-cool-name that it does apply to you.

Especially looking to the size of your dev team, I think the worst things that could happen to you in your journey of trying to be a "better developer" is to try to be use too complex tools and too complex developments techniques

these articles explains better what I mean:

https://programmingisterrible.com/post/139222674273/write-co... https://medium.com/@rdsubhas/10-modern-software-engineering-...

Being able to stop your fellow developers from writing too smart code will be even more valuable for the companies you will work for. And at the end of the day, that what will define if you are a good software developer for your boss.

More than best practices, what makes a great developer valuable (especially in a position like you where other people in your company are less experienced than you) is your ability to see wider not deeper."

Yes, you need to balance the need to be proficient with the stack that you have now with the big level-ups that come from learning something quite different. The best way to grow as a developer really is to learn a different programming language, and the thinking that goes with it.

I've never written a line of production code in Clojure, but learning Clojure taught me lessons about immutability and functional thinking that changed the way that that I wrote everything afterwards.

Best practice tip: no developer should be an island. You should all have some idea what each other is doing, at least once a week. You should be reviewing each others' code, and asking about the decisions and tradeoffs involved.

Totally depends on the startup. Building a new blog engine? Sure, go wild. Making financial software? You need to be very careful, and write good, secure code.

Shop Class as Soulcraft, by Matthew B. Crawford. This is a much more philosophical/academic argument that skilled manual labor is both intellectually and morally superior to most office work - you're shaping reality, rather than shaping yourself. I happily lump the craft of software development in with physical labor here, though, as it faces the same kinds of reality-based limitations.

Zen Mind, Beginner's Mind, by Shunryu Suzuki. Transcribed lectures by a well-known Zen monk. The entire book is basically about learning how to sit still. If you can't even sit still, how do you expect to do anything else well? And do you have any idea what it even means to just sit still?

I also liked Mastery by George Leonard [2] - it's a little booklet about mastery with the same kinds of generalisable takeaways, drawing on his experience as an Aikido practitioner.

[1] https://www.jstor.org/stable/202063?seq=1#page_scan_tab_cont...

[2] https://www.goodreads.com/book/show/81940.Mastery

1. Visit a complex web app, check if source maps are enabled.

2. Using Chrome DevTools, download the sources and source maps.

3. Install shuji, https://github.com/paazmaya/shuji

4. Run shuji recursively on the source maps to output normal code.

5. Review Components/code to see how current companies are carrying out (best) practices, etc.

For me, it helped break down how different companies (with closed source) are structuring React/Redux code for complex apps.

1) learn (read guides, books, code)

eg: find something close to what you're doing at one of the books at: http://aosabook.org/en/index.html

Read about nginx if you're working with web servers - even if your server is in node. Read about postgresql or mysql if you work with data. Etc.

2) implement

Try things out. Do a module in ttd (red/green/refactor). Pack a sub system up as a node module, distribute it on npm.

3) automate

If you have any tests - set up CI. See that all your commits "pass" (ok, because you only have that one test - but now it's easy to add more).

Once CI is working, you can set up automatic lining.

4) repeat/improve

In general, try to find the smallest step from where you are, towards where you want to get to. Avoid leaps. Change one thing at a time (eg, you've used mongodb+node+express+react: try using typescript or change out react for vue. Or look at using postgres over mongodb etc.

I'd also try to encourage some kind of internal sharing. Maybe tech lunch Friday - where you can each give a lightning talk on some small nice thing you've found/used recently.

Try to "budget" for improving. Make it work, then spend an hour or two making it (more) beautiful.

Specifically, how do you learn how to build a company around your product? Or how to build a board of advisors/directors? What are the best practices around managing those?

How do you shift your cash flow management thinking from spending out of the reserves built up, to spending out of future cash flows?

In other words, aside from building product, there are so many other skills that a founder has to learn as they grow their company. I assume most YC companies learn this stuff from YC or their batch mates that have done it before them.

But for those of us not in the Valley or in YC, how do we learn this stuff?

Also, I guess the main premise behind my question was how do we learn best practices in company building in general? Ie how do we build the machine that builds the machine using best practices for everything, or as many things as possible (for both tech and non-tech companies)?

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.

2. 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...

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.

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...

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.

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.

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

If the 10k line UserManager class has you pulling your hair out, you know you have a problem.

“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).

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”.

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.

This, of course, coming from a person with burn marks :)

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.

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.

Other than that, just consume multiple sources of 'best practices' recommendations and see where they line up. Figure out what works by applying what you read and form your own opinion.

Other people have mentioned that "best practices" can be a double edged sword. Software engineering is very varied and it's hard to abstract out "best practices" that apply in all situations. Don't get blinded by "principles" and evaluate each technical situation on its own merits and weigh the tradeoffs of the solutions you can think of before proceeding. There are way too many variables for you to have a playbook that reads "in x situation do y" most of the time.

With regard to best practice being institutional, you'll formulate a lot of it on your own as the org grows (if it does.) For example, having code reviews would widely be considered a best practice across the industry, but in your situation it is obviously not reasonable. Who would review your code? You? Lots of institutions have style guides for software engineers (I would consider this a best practice) to keep software easily readable to as many team members as possible. In your situation, what engineers are you trying to keep on the same page? None? In your case, this is then not a useful best practice.

There are community best practices that sometimes spring up around quirks of the language and its tooling. I would say the best way to deal with the first is to use a lint. That will teach you a lot. The second is something you usually have to get bitten by to find out.

Finally, read a lot of code in your language/framework of choice (critically of course.) You'll learn a lot of tricks, and will also see a lot of traps to avoid by doing this. If you're in Node, reading the source to Express is probably a good place to start and is obviously applicable to your work (and can only pay dividends in that respect.)

Here's many more papers http://www.cs.cmu.edu/~NatProg/apiusability.html and here https://sites.google.com/site/apiusability/resources

Check 'cited by' to find more papers

- hours of youtube conferences

Sometimes learn is impossible at work, or...

i had and experience... i was working for a bizarre company, the culture was very far from what i could consider decent, in some cases they were toxic. Nobody could understand what i was trying to say/do. MSSQL, C# and other very cool stuff.

But wait... they weren't able to understand what i was doing but... i was able to understand what their business was, their special use-cases, their customers and requirements.

Those moment are in the past now. But i learned a lot from people that could not understand me, having a completely different background.

Everybody can teach us something...

1. Read - books and articles about what you are doing

2. Go to conferences and meetups and ask questions

3. Make learning and self-mentoring part of your daily flow

4. See mistakes as learning opportunities and get your team to see it the same way, talk about mistakes with your team

5. If possible, find someone to mentor you externally, maybe even just an hour or two a month, just to ask them questions

Learn how to learn and how to figure things out. A mentor is there for perspective and pointing you in the right direction. Working with other like minded people that can help you at least think of things from a different perspective can go a long way.

1. by doing a job and making mistakes

2. by studying theory

3. by observing how more experienced colleagues do a job that is very similar to yours (design review, code review, pair programming, daily conversations)

You are already using the 1st way.

You definitely can use the 2nd way by reading books (Martin Fowler, Bob Martin, Eric Evans, Kent Beck etc.), watching some video courses, reading code of open source projects, etc.

But in your case it is almost impossible to use the 3rd way. And as for as I know the 3rd way is far more efficient then others. I would propose to quit the job where you can't use the 3rd way.

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.

That is not to go against other advice in this thread about watching videos, reading other books, making lots of mistakes, and so on. And it's also not to imply that there is a single 'best practice', either.

But what this book gives you is a load of solid places to start, on many different subjects that are important for developers. Subjects like issue-tracking, code style, how to learn and stay up-to-date, tests, infrastructure, resilience, working in a team, sharing knowledge, and so on.

It doesn't relate to any particular language or architecture. And it has some great tips for the situation you describe, where you are trying to do a good job in the context of a team that doesn't have any clearly defined practices.

I'd buy the paperback, not an eBook, and scribble in every margin. When you've read it, carry it with you and dip in and out.

Once you have read this, then a lot of other sources of material will make a lot more sense. Some of them might contain better ideas than those in this book, which is fine; the great thing about reading this book is that you'll be in a good position to evaluate other ideas.

I google around for recommendation on books and get books and read them and do projects. Books will go over a concept but it won't be enough for me to get it in my head so I would google around for blogs about the concept and do the examples in those blogs. Here's an example of me practicing the GenServer concept (https://github.com/mythicalprogrammer/elixir_genserver_pract...). I also find code reviewing of library very helpful in writing better code. I used to do this with Scala and Javascript.

Most of the stuff I've learned is on my free time and something I'm passionate about. Currently it's Elixir. I spent sometime reading and then did a project. Currently burnt out from the project but I learned a lot and I'll come back to it.

I know many people just jump in and do stuff. What works for me is to read a bit do project then read a little bit more. My elixir project went through 3 authentication systems btw. I started with Coherence then Guardian then Coherence and now POW. I relearn session and learn a bit more about tokens and API.

Now, here are what I think is the most important: experience, planning and critical thinking. Experience you gain overtime, there is no shortcut. But you can plan from the beginning, and think hard before you commit.

You're already asking yourself the questions. The internet is vast, there are lots of answers. And guess what, someone's best practices are someone's else bad practices. It's about your company trade-offs.

Since you are in a startup, you'll probably need to do lots of modifications on your business logic. That means for you, API development best practices includes planning for the future, so probably having versionned API. Is your business logic mostly about CRUD? Read up about REST. Or mostly about RPC? Might want to read up about SOAP.

You also need to know what's the time expectency of your code. Is it just a POC? Go ahead with the fastest, dirtiest way to do it. Is it a MVP that is going to change quite a bit? A bit cleaner, but you can get away with a few shortcuts. Or are you building a well-defined product that isn't going to change much? Document, test, and do it as clean as you can. You are still going to need to refactor a bit every year or two anyway, when you get more experience.

Keep at it long enough, while thinking about better ways to do things every day, and eventually you'll learn all you wanted to know. Don't worry, you'll still have a ton to learn, given the opportunity.

Why would one use SOAP over grpc in a new stack? Understandable in an old stack though.

Rest is gold.

Also, we don’t always get to choose the technologies of 3rd party providers with whom we are required to interface.

——

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.

1. Consume external knowledge by reading books, watching videos, taking classes, etc.

2. Apply the new knowledge, plus your intrinsic store of knowledge to whatever problem you're working on.

3. Note mistakes, lessons learned, synthesis of ideas between "new" and "old" knowledge, etc. Update your bank of intrinsic knowledge.

Lather, rinse, repeat.

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.

For example, I built my first production application taking a database connection from the pool in middleware and then returning it to the pool at the end of the response. My much more experienced friend looked at my code and told me that connection pools are made for taking out connections and returning them to the pool as soon as you were finished with them. And that I should use timestamptz instead of timestamp. And so much more.

It makes me cringe to think how long I would've gone without figuring out these things had it not been for someone to set me straight early on.

Meetups.

Hackathons.

Reading books (google for "best software books" and you'll find some lists).

Hanging out in online communities whether general (like HN) or language/tech specific.

Read articles.

Follow interesting people/companies on twitter.

Blog about your work.

All of the above can help, but you need to pick what works and is fun so you can stick with it.

Most (really, honestly, most) developers are interested in the way they do things and aren't opposed to teaching new people the ropes, so I don't think it's unlikely that you'd be able to get this through.

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.

Your public apis should be based on the shape of your data. I would prefer postgres over mongodb because your data probably has a schema.

If you have the time, learn some other languages. Each language has their own ecosystem where problems are approached slightly differently. You'll pick up patterns and be able to apply them to your work. I would recommend elixir, which has a very focused ecosystem and a standard library with well thought out apis.

I follow several public and private projects that I do not contribute at all. Any time there is a review comment on a pull request from senior devs, I try to check if it is new to me. If so, I note down the problem and suggestions.

Here are some examples:

- Aleks suggested to limit the try to the places where exceptions can be thrown and move everything else out of the try.

- Thomas suggested to use =StringBuilder= instead of =String.format=. The former is faster and more robust.

- Oscar suggested to use a =parameter object= or a =builder= when there are many (more than 3-4) parameters.

You don't need to know almost everything (and derive what you don't from first principles), that is unreasonable. You do need to have a network of folks you can ask help or feedback from.

Being on a small team without much support will force either very fast growth or failure, and your ability to be intellectually honest (is this true or do I want it to be true?) and identify folks who can and are willing to genuinely help are important factors.

Not so much mailing out code reviews, but sharing design ideas, approaches, etc. Former coworkers you are still friends with, open source collaborators you have become close to, etc all work.

Basically, build and maintain relationships with people who have good judgement. Help them out, ask for help yourself.

- ex-boss

Also,find out why something is or isn't a good/bad thing to do.

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.

It’s dense and visual. It’s also more carefully crafted and corrected through time then say blog posts, online videos or podcasts. Compared to a coach or a teacher, you also are getting the actual root of the information and not a distilled and approximate version of it. Even when the person teaching is the one who actually wrote the book!

"This is the feature I worked on, I chose this approach, any suggestions?"

Isn't this likely to change for you one way or the other reasonably quickly given that you're at the earliest (most volatile) stage of a startup? Unless you drag things out longer than they need to in denial of failure, you're going to either be building a team or joining one shortly enough.

Otherwise I'd suggest to look at projects that the "community" deems well written.

https://news.ycombinator.com/item?id=18794561

My best advice would be to try and use one of the publicly published coding standards from a big company as there is usually a lot of good knowledge/experience baked into those. Use a linter religiously and do not commit code with lint errors. For every commit, take a step back and think "is this code shit?" If I had to explain it to someone who I thought was a 'better' or more experienced coder than me, would I be embarrassed about it?

Generally you'll get a gut feeling about code being good or bad - how reliable it is, how often you have to tweak it, how easy it is to change etc. If it is hard to make changes to some code or its really buggy or brittle then trust your gut: You Are (probably) Doing It Wrong. That is when you can go and read around different approaches online to see what other people have done to approach the same/similar issue and learn from them. Some approaches will resonate with you, some won't. Make a professional judgement on which (if any) you want to learn from/emulate in your codebase and why you made that decision (the thought process helps - sometimes you just need an 'ah ha' moment to work out your own approach)

tl;dr - beyond fundamentals, everyone does things differently. Do what works for you and what is reliable and maintainable.

https://github.com/tallesl/Rich-Hickey-fanclub/blob/master/R...

I find I learn a lot as a developer who doesn't use Clojure

After you have some more experience (and confidence) start reading books. Your first one should be Code Complete 2.

Break stuff. Fix it. If you can't fix it ask for help. Rinse and repeat.

The key here is your journey to get experience. Every time you try something, you will be using your past knowledge. To speedup things you should learn from others' mistakes _too_, but don't forget to learn from yours.

Just my 2 cents.

PS: Good luck!

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...

I don't know why, but in my experience software practitioners are apt to be incurious and beginner-hostile. They tend to expect questions to be absurdly well-formed-- almost to the point of answering themselves. I believe this is part of the reason why stackoverflow seems like it is overrun by assholes.

The fact is, the best way to learn anything is by having a good teacher or mentor. A truly good teacher won't merely answer questions. A good teacher ASKS QUESTIONS and provokes the student into discovery. Good teachers are rare, but they aren't necessarily subject-matter experts, they just need to be a few steps further than the student along the path.

Even if you don't have someone that you can call a mentor, you can get on a rewarding path to learning new stuff by forming a workshop to learn a subject with colleagues. Exploring new subjects and solving new problems together with another person is an amazing and energizing way to learn things. It almost doesn't matter what skills you have relative to others, if you're far ahead in some topic, you will get better in it by teaching it to someone. If you're far behind, you can depend on the other to give you some clues for proceeding. If the chemistry is good and the environment allows it (not a sweatshop) this will work just fine.

1. Practice writing new project's from scratch. not so much todo apps but challenge yourself e.g. I wrote my own function as a service engine

The main point of the exercise is to show: - Best practice is contextual, so first you need context ;) - Think about the big picture and all the pieces to get there - Repetition. It will help you improve your development flow and process, and become better at your craft

You can borrow design/implementation ideas from current projects that you're familiar with or use a design pattern you found on a blog etc. it will help you recognize when certain practices are the "best".

2. Rewrite this code continually. Is there a better way? more concise? faster? easier to test? It seems there's many ways to do the same thing. Which one is best depends on the situation.

3. Optimize last. No seriously. If I could count, the amount of times I've thrown away code because I optimized to early...

tl;dr best practice needs context. This requires big picture thinking. Learn to recognize contexts and the best practices are alot clearer

This is probably not popular advice, but of all the places I've worked, Google seemed to have the highest standards for best practices I've seen. I recommend paying attention to Google's best practices, in their blogs, certification programs (like the google cloud developer cert), Coursera courses, product docs, codelabs, style guides, git code, etc. Obviously everything they do won't be a right fit for your company, but it's something to aim for.

Enforce code style (be specific and use a linter), and write tests as you go. Try to keep bad code out of your repo before PRs can even be merged. I use Jenkins and git hooks to enforce this for the whole team.

Draw up design docs and understand business needs before diving into projects and features.

Understanding good architecture and operational principles will make you much more valuable as a developer than your peers. Read the Google SRE book, it's free. Also read http://highscalability.com/ articles and learn from other companies' triumphs and mistakes.

Books about architecture include the micro services book by Sam Newman. You may not ultimately be responsible for making these decisions, but demonstrate your value by being able to understand and provide quality feedback to your tech leads and architects.

Study and learn about project management techniques and craft/enforce your process. Not everything boils down to good code and architecture, if your development process sucks, everything else will definitely fall apart.

Be able to spot the flaws in your organization and offer ways to improve their process and quality. By doing so, you will also improve your own.

If you have a cloud provider and a support package, use it often. Most of what I know about best practices came from supporting Google Cloud customers, seeing what they were doing poorly, and working together to find better solutions.

Be sure you're not just abstracting your API libraries, but your use of 3rd party libraries and services as well. You don't want to have to refactor all of your code just because you need to swap out one technology for another.

If you're actually better than the rest of your team, you should be mentoring them. Teaching others is incredibly helpful at solidifying our own understanding of topics, and exposing the gaps in our knowledge.

Read "The Phoenix Project". It probably applies more for the DevOps/SRE/Management side of things, but I think there are VERY important lessons to be learned for everyone in there. Highly recommended.

The path to enlightenment leads through suffering. I particularly like "Why I stopped using X" or "X sucks" or "Pitfalls when using X" kind of blog posts. Browsing Stackoverflow to see what kind of issues other people run into also can help sometimes. Focus on the negative. If nobody complains about it, it's probably not a real problem.

That's also why I'm often skeptical about so-called "best practices". It gives people excuses to do questionable busywork passed off as "polish". Real work is not about getting an A+ with a smiley face, it's about choosing the trade-offs that provide the most value. That implies cutting out a lot of "nice" things that aren't strictly necessary.

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.

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.