The NSA's Surveillance Is Unconstitutional - <AUTHOR> http://online.wsj.com/article/SB10001424127887323823004578593591276402574.html?mod=rss_opinion_main

<comment><USER2> Does anyone realistically think this program will be rolled back?

Presuming for a moment that all the information collected by NSA is, in fact, public information, it seems to me that the primary problem isn't collection but asymmetric access and hence power differential between the state and those governed. Why should the government have exclusive access to this information while the general public doesn't? If this treasure trove of personal connection graphs, cell phone discussions, location information, is all truly public and not subject to a judge issued targeted warrant, then, why shouldn't this public information be available to any member of the public?

This new information could be a boon for Democracy and completely change how we understand and interact with Government. Why shouldn't technology impact how we organize our society? Politicians and civil servants, who have the consent of the governed, take an oath to uphold the constitution and put the interest of the people above their own. If the general public should be tracked to such precision, at the very least, why shouldn't interactions in the public affairs of our elected and appointed and contracted officials, done on our behalf, be subject to the same level of scrutiny?

<comment><USER3> >Does anyone realistically think this program will be rolled back?

I for one plan on making a ton of noise until that happens.

<comment><USER4> We've been making noise since 2001 before the Patriot Act was passed, then in 2007 when they granted retroactive immunity to the telecoms who where assisting with the illegal wiretapping, and now again in 2013 when we received some PPT slides that confirm what we thought in 2001.

I'm not trying to be a negative nancy, nor saying stop making noise, just that it's been going on for 12+ years (if not longer) and the powers that could stop it can hardly tie their shoes without an argument on how to tie them correctly. Hopefully more people will wise up to the blatant disregard for the law and demand further action.

<comment><USER5> Disclaimer: This is not directed at disposition in particular, it's more of a general observation.

> I'm not trying to be a negative nancy, nor saying stop making noise, just > that it's been going on for 12+ years (if not longer) and the powers that > could stop it can hardly tie their shoes without an argument on how to tie > them correctly.

The length of time that something has gone on does not change the fact that it is fundamentally wrong. The only difference is that I am now, 12+ years later, more disgruntled than I was back when it started. I feel like some people use the fact that this has been ongoing as some way to say "Oh, this isn't as big a deal as you're making it out to be." No, screw you.

Also, we as a population have to stop with the "it's never going to change, why bother?" mentality and get involved. It's definitely never going to change if we continue to be so apathetic as a group.

<comment><USER6> > No, screw you.

This is how I feel every time I hear someone make excuses for things like this. It's less "screw you, I hate you" and more "screw you, wake the hell up".

</comment></comment></comment></comment></comment><comment><USER7> The NSA stated, in 1975, that it's not bound or beholden the US Constitution or law. I don't expect that their opinion has changed much. I can't recall any lawless institution that all of the sudden became lawful of its own accord:

> "NSA does not have a statutory charter; its operational responsibilities are > set forth exclusively in executive directives first issued in the 1950s. One > of the questions which the Senate asked the Committee to consider was the > "need for specific legislative authority to govern the operations of...the > National Security Agency."

> According to NSA's General Counsel, no existing statutes control, limit, or > define the signals intelligence activities of NSA. Further, the General > Counsel asserts that the Fourth Amendment does not apply to NSA's > interception of Americans' international communications for foreign > intelligence purposes."

> > [http://www.aarclibrary.org/publib/church/reports/book3/pdf/C...](http://www.aarclibrary.org/publib/church/reports/book3/pdf/ChurchB3_10_NSA.pdf)

<comment><USER8> Ignoring whatever laws have been passed since then, not to mention the control of the purse the Congress has, your excerpts don't make your case. E.g. by saying "the Fourth Amendment does not apply to NSA's interception of Americans' international communications for foreign intelligence purposes" the NSA was implicitly also stating that Americans' communications that didn't meet those criteria were protected by the Fourth.

<comment><USER7> > Ignoring whatever laws have been passed since then

I trust the NSA to do just that.

> the control of the purse the Congress has

They increased the NSA's budget by $4 billion last year.

You're more than welcome to trust an agency with little to no oversight. I'll keep my faith in human nature. It's served me well all these years.

<comment><USER9> Well the NSA's activities have strong bipartisan support (at least as long as as the public doesn't have a great idea about what it does). No member of the intelligence committees has changed their position as a result of these recent disclosures. Both republicans and democrats have rushed to defend the NSA.

The problem isn't a rogue agency that doesn't have oversight. The problem is the law that allows the NSA to do just that. Take section 215 of the patriot act for example(it allows the government to obtain business records aka the verizon phone provision ); it is written in a way that makes it laughably easy to use for almost any use at all. The FBI doesn't even have to go to the FISA court but can choose any magistrate judge they want. The only restriction is "that such investigation of a United States person is not conducted solely upon the basis of activities protected by the first amendment to the Constitution." Wonderful......

<comment><USER7> > Both republicans and democrats have rushed to defend the NSA.

In terms of realpolitik, that only makes sense. Politicians will defend anyone that they think might have the dirt on them. Intelligence apparatuses in all ages exist to control the political class.

Hoover's reign at the FBI is a history of political control via intel.

</comment></comment></comment></comment></comment><comment><USER10> > private communications companies with which citizens do business under > contractual "terms of service." These contracts do not authorize data- > sharing with the government.

How come Aaron Swartz gets prosecuted for violating a TOS and the government doesn't?

<comment><USER11> Because the government has lots and lots of guns.

</comment></comment><comment><USER12> OF COURSE its unconstitutional. However, I don't see the point of even debating it. It's like when people got super excited that citizens were suing the NSA to obtain this data as if there were anything other than a 100% chance they would be denied.

There are a few possible outcomes to this debate:

-The NSA says, sure, its unconstitutional, but that wont stop us from doing it.

-The NSA continues to deny/lie about what they are doing with the program.

-The NSA appoints an oversight committee with no actual powers to make sure they "don't continue to do the same thing"

-No comment, forever.

Any of those options mean that the NSA keeps doing the same thing, tells us to STFU and we realize we have no recourse. I hate to say it, but it seems like this debate will have to end in violence or it won't end at all. :\

<comment><USER11> There is one other possible alternative: those of us who feel strongly about this issue need to get into politics. If enough of us get in (obviously we'd have to adopt one of the big two parties, and start getting support at local or state levels first) we could shut this stuff down from the inside.

Of course, we'd need some protection against people defecting for the money. Maybe everyone has to make treasonous statements in front of a camera that we all carry or something, so if someone sells out we can have them jailed or executed for treason.

</comment></comment><comment><USER13> The part about the CFPB is the next unknown hammer to drop. Consumers assume the CFPB is on their side. The truth is far murkier. For instance, the CFPB has requested and was granted detailed financial transaction information on at least 10 million Americans. Of course, they are claiming that "personally identifiable" is "extremely limited", but like the phone meta-data issue, it is clear detailed spending habits could be associated with certain individuals. At least they promise to destroy the data after holding it for 10 years... Source: [http://blogs.marketwatch.com/capitolreport/2013/07/09/cfpb-c...](http://blogs.marketwatch.com/capitolreport/2013/07/09/cfpb- criticized-during-data-collection-hearing/)

</comment><comment><USER8> Some framing, usual comment section, etc. by him at the _Volokh Conspiracy_ : [http://www.volokh.com/2013/07/11/unprecedented-my-wsj-op- ed-...](http://www.volokh.com/2013/07/11/unprecedented-my-wsj-op-ed-on-the- nsa-cfpb-blanket-data-seizures/)

</comment><comment><USER14> Genuine question: how many decisions are made at the legal/policy level based on something being 'unconstitutional?'

<comment><USER11> None I would say. The legislative makes the laws and assumes the executive won't enforce them if they're bad and/or the judicial will throw them out if they're not constitutional. Of course, plenty of things that are obviously unconstitutional don't come before the court for years if ever so they can't be struck down.

</comment></comment><comment><USER15> This article is trash, the discussions on this issue are trash, and everyone is running around like a headless chicken.

A Law Professor, writing an argument about law, without discussing the relevant cases? No discussion of Smith v Maryland? No discussion of FISA 702 or Patriot Act 215? Did he even bother to look up any relevant information with regards to this controversy?

Call it unconstitutional if you want, but I want to see an _argument_. Call yourself a law professor or a lawyer, but if you write under the guide of a legal expert, I demand to see a high level discussion on the issue.

Instead, I get a rant about libertarian ideals, applying the 5th Amendment to property you clearly do not own. I see vague descriptions of the 4th Amendment, with no regard to context that is going on in the debate in Washington.

Any "Law Professor" that writes about this subject... but FAILS to mention Smith v. Maryland is horribly horribly ignorant on the subject. And does not deserve to be writing under the guise of a legal expert. And he has failed to do his due diligence as both a legal expert and reporter.

<comment><USER8> Is _Smith v. Maryland_ really all that relevant?

Isn't there a big difference between collecting data from " _a_ " pen register, and putting pen registers on every single phone in the nation? (And claiming that's not "collection", collection is only invoked if and when they decided to look at stored data?)

<comment><USER15> Smith v. Maryland is relevant because it is being discussed by the Senate Intelligence Committee and debate in Washington. Its part of the discussion, its part of the debate. Period.

The author of this piece has failed to communicate part of the discussion from within Washington to the rest of his readership.

<comment><USER16> Let's bring Rihanna and Bieber into the discussion as well. Surely there's some way we can make them relevant to the discussion of NSA spying, then we can complain about law professors not including them in their articles either.

If "It[']s part of the discussion, it[']s part of the debate. Period." were a general rule of debates, then it would be ridiculously easy to sideline a debate by introducing random irrelevant facts to the discussion.

<comment><USER15> Precisely why I'm annoyed at the author.

Please tell me why Mr. Barnett's rant about 5th Amendment rights in Colonial America is relevant to the conversation... but Smith v Maryland isn't.

Yeah, that's not a typo. Barnett begins to rant about the _Fifth_.</comment></comment></comment></comment></comment>


Wire Transfers Now Supported - <AUTHOR> http://blog.dwolla.com/wire-transfers-now-supported/

<comment><USER2> This is incredibly helpful. Wire transfers at big banks (like Chase) cost around $20 per transfer. With Dwolla, it's 25 cents.

<comment><USER3> I believe the initialing bank will still hit the account holder with a fee to wire transfer to Dwolla.

<comment><USER4> I can transfer money from my bank account to my paypal account with no fee.

Why is there a fee to transfer money to Dwolla then?

<comment><USER3> That is considered an ACH transfer, which is the same way that you normally fund your Dwolla account. A wire transfer allows larger amounts and is much quicker but usually has significant fees attached to it. ( As well as some other differences)

[http://en.wikipedia.org/wiki/Automated_Clearing_House](http://en.wikipedia.org/wiki/Automated_Clearing_House) [http://en.wikipedia.org/wiki/Wire_transfer](http://en.wikipedia.org/wiki/Wire_transfer)

<comment><USER4> So can I transfer money into my Dwolla account with ACH, and then wire transfer that money to someone's bank account (possibly oversea)? That way the whole process would be free.

</comment></comment></comment></comment></comment><comment><USER5> I don't know why, but it's surprising to me that Dwolla has only been around for five years. They seem much older to me -- not in a bad way, I just feel as though they've been around much longer than they actually have been.

<comment><USER6> Strange I thought they only launched in late 2011. So to me they still seem "new." There was a raft of financial services api companies that popped up around the same time (recurring billing ones, swipe, square, etc)

</comment></comment><comment><USER7> they should support bitcoin wire transfers next..

<comment><USER8> Doesn't Dwolla hate Bitcoin?

</comment></comment><comment><USER9> As asked on the post, is this just domestic or international wire transfers?</comment>


A nondeterministic Turing Machine simulator in C - <AUTHOR> https://github.com/0novanta/nondeterministic-turing-machine-simulator <comment><USER2> Thank you for sharing!

For comparison, here is an interpreter for non-deterministic Turing machines, written in the logic programming language Prolog:

        turing(Name, Tape0, Rs) :-
                phrase(turing_(s(q0), Name), [[]-Tape0], [_-Rs]).

        state(S0, S), [S] --> [S0].

        turing_(final, _) --> [].
        turing_(s(Q0), Name) -->
                state(Ls0-Rs0, Ls-Rs),
                { right_symbol_rest(Rs0, Symbol0, RsRest),
                  tm(Name, Q0, Symbol0, Q, Symbol, Action),
                  action(Action, Ls0, Ls, [Symbol|RsRest], Rs) },
                turing_(Q, Name).

        action(left, Ls0, Ls, Rs0, Rs) :- left(Ls0, Ls, Rs0, Rs).
        action(stay, Ls, Ls, Rs, Rs).
        action(right, Ls0, [Symbol|Ls0], [Symbol|Rs], Rs).

        left([], [], Rs, [b|Rs]).
        left([L|Ls], Ls, Rs, [L|Rs]).

        right_symbol_rest([], b, []).
        right_symbol_rest([Symbol|Rest], Symbol, Rest).

I have adopted the convention that _q0_ is the starting state, and _final_ is the final state.

For example, here is a (deterministic) TM that computes _N+1_ , for a natural number _N_ specified in unary encoding:

        tm(plus1, q0, 1, s(q0), 1, right).
        tm(plus1, q0, b, s(q1), 1, stay).
        tm(plus1, q1, 1, s(q1), 1, left).
        tm(plus1, q1, b, final, b, right).

Sample query and answer:

       ?- turing(plus1, [1,1,1], Ts).
       Ts = [1, 1, 1, 1] ;
       false.

And here is a deterministic machine that computes the identity function id( _X_ ) for any natural number _X_ :

        tm(id, q0, 1, final, 1, stay).
        tm(id, q0, b, final, b, stay).

Combining the two machines, here is a machine that _non-deterministically_ computes N+1 _or_ the identity function at each step of the computation where the state is q0:

        tm(plus1_or_id, Q0, S0, Q, S, A) :- tm(plus1, Q0, S0, Q, S, A).
        tm(plus1_or_id, Q0, S0, Q, S, A) :- tm(id,    Q0, S0, Q, S, A).

Sample query and answer:

       ?- turing(plus1_or_id, [1,1,1], Ts).
       Ts = [1, 1, 1, 1] ;
       Ts = [b] ;
       Ts = [1] ;
       Ts = [1, 1] ;
       Ts = [1, 1, 1] ;
       false.

Note that alternative solutions are reported on backtracking.

<comment><USER3> Why are you using DCGs for turing_//2? Genuine question, because I implemented a TM interpreter in Prolog, using "normal" predicates, and I can't see where they help you in this case

PS: I learnt how to use DCGs thanks to your website, thank you!

<comment><USER2> That's a justified question! I'm using DCG (semicontext) notation here analogously to _monads_ , mostly to benefit from having to keep track of fewer explicit arguments that need to be passed around.

In this concrete case, using them explicitly is certainly not bad and may even be preferable. However, suppose I now introduce a new argument in order to implement _iterative deepening_ :

        turing(Ls, Name, Tape0, Rs) :-
                phrase(turing_(Ls, s(q0), Name), [[]-Tape0], [_-Rs]).

        turing_([], final, _) --> [].
        turing_([_|Is], s(Q0), Name) -->
                state(Ls0-Rs0, Ls-Rs),
                { right_symbol_rest(Rs0, Symbol0, RsRest),
                  tm(Name, Q0, Symbol0, Q, Symbol, Action),
                  action(Action, Ls0, Ls, [Symbol|RsRest], Rs) },
                turing_(Is, Q, Name).

Then this notation, in my opinion, already makes it a bit easier to think about the rule, since it only uses 3 arguments instead of 5 or more, and the tape is simply passed along implicitly.

An _iterative deepening_ version of the machine provides the important benefit that infinite branches of the computation cannot block others that lead to (nondeterministic) succcess. For example, suppose I add the indefinitely looping machine:

       tm(loop, q0, 1, s(q0), 1, right).
       tm(loop, q0, b, s(q0), b, right).

and then define:

        tm(loop_or_plus1_or_id, Q0, S0, Q, S, A) :- tm(loop,  Q0, S0, Q, S, A).
        tm(loop_or_plus1_or_id, Q0, S0, Q, S, A) :- tm(plus1, Q0, S0, Q, S, A).
        tm(loop_or_plus1_or_id, Q0, S0, Q, S, A) :- tm(id,    Q0, S0, Q, S, A).

then we now get solutions via iterative deepening, whereas the original machine loops without reporting any solution:

       ?- length(Is, _),
          turing(Is, loop_or_plus1_or_id, [1,1,1], Ts).
       Is = [_3790],
       Ts = [1, 1, 1] ;
       Is = [_3790, _3796],
       Ts = [1, 1] ;
       Is = [_3790, _3796],
       Ts = [1, 1] .

Iterative deepening is an asymptotically optimal search strategy under very general assumptions. Thank you for the kind words!

</comment></comment></comment><comment><USER4> If I may add some context: this was a mandatory project for a course (Algorithms and Principles of Infomation Technology, CS&Eng BSc II year) held last year at Politecnico di Milano</comment>


Google Going After Dropbox - <AUTHOR> http://www.pcworld.com/article/249605/googles_gdrive_reportedly_to_launch_as_dropboxrival_drive.html

<comment><AUTHOR> Most significant line: "Unlike Dropbox, ...Google Docs' storage offerings are a bit more complex."

The beauty of Dropbox is its simplicity and seamless integration. Sounds like GDrive is more iCloud than Dropbox, so I'm not sure how accurate the term "Dropbox-rival" really is.

</comment><comment><USER2> Dropbox is fabulous product, easy to use and does its job very well. Not to sure if GDrive is going to be competition to it, unless and until GDrive tightly integrates with GMail, the must use offering from Google (other then Search).</comment>


Ask HN: How to learn best practices when you have no one to teach you? - <AUTHOR> 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.<p>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? <comment><USER3> Conference Youtube videos. They are a goldmine of useful tips and tricks. Go look for videos from the Node [1] and MongoDB [2] conferences and you will find tons of war stories and what is actually working for people. Using this option arguably connects you directly with some of the best people in the world who are actually using this stuff.

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...](https://www.youtube.com/watch?v=UMgMSb7d-Os&list=PL0CdgOSSGlBY7DBgOp1xsRvV31AAUZrX2)

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

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

<comment><USER4> I would say do not look to conference videos for how to write production quality code... Most talks at conferences are shallow and at worst just the blind leading the blind.

Be very careful, I've even seen people from places like Microsoft showing code at conferences that would fail even a decent code review process.

I think for this reason conferences are a complete waste of time. Talks are too short to go into anything approaching useful detail, and s spend an hour talking about pointless demo quality code.. Or the talkers arent experts in what they are talking about. Waste of time.

I would say the same for the majority of blogs. Most are garbage and it can be difficult to tell the code is garbage if you're a beginner. I dont know a single development blog worth reading...

<comment><USER5> The blind leading the blind? Most conferences have lineups of well respected people involved in an ecosystem. From language authors to open source maintainers and such.

It seems you don't seem to understand the purpose of conferences and blogs. These talks are not to showcase the best quality production code that can pass any review process. They are to showcase new developments and new approaches to do things in a specific field. It's meant for people already in the field (or starting to get into it) trying to learn more.

If such talks have high quality production code in slides the message would get easily buried under stuff that isn't important for conveying the message they are trying to say.

</comment></comment></comment><comment><USER6> "Best practices" is a bit of a red herring. Every company differs considerably, and online blogospher experts throw the term around as sort of a gatekeep-y way to keep the order ("What do you mean you don't know (arbitrary) best practices??!?!") The only way to learn best practices is to work at multiple companies / projects.

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.

<comment><USER7> I'll second that a lot of 'best practices' is cargo cult like gate keeping.

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.

<comment><USER8> 'idiomatic' vs 'best practices'?

<comment><USER7> My inner Northcote Parkinson sort of triggers on 'best practices'. Best tends to imply that all the other ways to skin the cat are 'bad.' Which is likely objectively untrue.

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.

<comment><USER9> They can mean very similar things so that the question could be:

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

<comment><USER10> To which I think we land on the recommendation: seek good examples and mimic them. Trouble is finding them.

<comment><USER4> It is. I work in c# and if we take idiomatic to be how most devs write c#, then idiomatic c# is garbage.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I did a quick control-f "read" and almost everyone is telling you to read books or articles about best practices. That might be useful once as a highlevel overview when getting started on a topic, but my personal advice is to only do that briefly. You'll get the most bang for your buck READING CODE. There is no better way to improve as a developer than reading good code.

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.

<comment><USER12> How do you learn to read code without guidance and without getting lost? How do you keep your thoughts organized? At each step, how do you confidently decide where to go next?

———

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](https://github.com/cypress-io/cypress) or [https://github.com/webpack/webpack](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?

<comment><USER13> I've spend my career reading code. I find it particularly difficult without guidance. I would recommend using some old school technology (pen/pencil and blank paper) and draw diagrams, write down every question and observation, notes. Others may recommend using some digital tool, but be mindful how much energy you spend organising your thoughts, drawing with a digital tool. If your goal is to understand a software, then don't waste time creating beautiful documentation first.

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.

<comment><USER14> This is all great advice. Two things that have helped me in particular

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

<comment><USER12> > "How to Read a Book"

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.

</comment></comment></comment></comment></comment><comment><USER15> Adding on top of what others have said..

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

</comment><comment><USER16> In general I think it's good to be in touch with communities centred around your language and framework to get a good idea of how people are solving similar problems to yours. Things change so much over the years and there are multiple ways to solve the same problems that you won't get from just reading official documentation. Once you get a sense of the general playing field you can deep dive into certain topics.

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/](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/](https://androidweekly.net/)).

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

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

</comment></comment><comment><USER18> I'd like to give a contrasting answer, which is that you should go somewhere where you can be mentored and learn. If you're concerned about your ability to continue learning best practices and level up as an engineer, you should keep in mind that there are many engineering organizations where you'll be able to work directly with engineers much more senior than you who you'll learn a lot from -- in my prior experience, it was this kind of collaboration that I learned the most from. It's true that I learned a lot when I was younger from self-teaching and experience, but there was a certain amount that I'm not sure I could have (or should ever have) picked up on the job in production, because it would have been infinitely more painful and less productive than collaborating with someone who could help guide me in the right direction, as well as whom I could look up to as a mentor and a guide.

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.

</comment><comment><USER19> All of these responses are missing a huge point here:

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.

<comment><USER20> I massively disagree with this, as the other part said a lot of standards don't make any sense. REST always seemed very suspect to me, and Facebook with some of the best developers in the works basically threw it straight out of the window with graphql, seeming to validate the scepticism. Html also has complicated standards about elements which everyone ignores with divs everywhere. There seem to be a lot of nonsense standards around.

<comment><USER19> The reason you massively disagree with it is the reason why OP should try and do it. Nothing better than learning from the mistakes of others.

</comment></comment></comment><comment><USER21> You have a lot of people to teach you! It's just that they use books and GitHub repos to communicate :)

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.

</comment><comment><USER22> "Best practices" are not the best way to think about your output nor your (personal) development.

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.

<comment><USER23> I think you're somewhat taking down a strawman here. Some practices (e.g. using source control, being super extra careful about state changes) are indeed almost always best, and it's rather likely that you'll also learn when to use them for the best practices you do learn. We're - so I hope - <USER2> talking about some nonsense like learning design patterns by heart or some such.

<comment><USER22> Using source control is basic and vague, the specific practices around it you might be tempted to call an education are just as subject to getting lost in dogma vs. developing personal wisdom as anything else.

</comment></comment></comment><comment><USER24> I don't think this will help tremendously, but don't feel frightened if there is nobody to mentor or push you. When I started fresh from college (although that is some kind of experience), I found myself in a small start-up with 4 people, one of which was my good friend, but we were not leaders, just executors. The owner was the business guy, with little technical knowledge. Nevertheless, we pushed on hard. Learned ourselves (each of us four had little overlap, we interfaced). And you know what, although I felt lost and disoriented, I learned a lot, in perspective. Partially because I was inexperienced, but everything we did was quality, I must say.

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.

</comment><comment><USER25> I would like to point out a possible problem with the generic advice "read books" "follow blogs etc."

=> 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://programmingisterrible.com/post/139222674273/write-code-that-is- easy-to-delete-not-easy-to#_=) [https://medium.com/@rdsubhas/10-modern- software-engineering-...](https://medium.com/@rdsubhas/10-modern-software- engineering-mistakes-bc67fbef4fc8)

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.

<comment><USER26> "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."

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.

</comment></comment><comment><USER27> > 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.

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.

</comment><comment><USER28> Don't worry about good code at a startup. Worry about building something people want. Once you hit hockey stick growth you can hire the technical talent.

<comment><USER29> >>Don't worry about good code at a startup.

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.

</comment></comment><comment><USER30> A lot of it is about learning how to learn. Developing skill and mastery is a similar problem in almost any field, and you can learn a lot by reading from masters in other fields. I'm currently reading _Handmade: Creative Focus in the Age of Distraction_ , by Gary Rogowski, who makes furniture. The first half of the book, at least (that's how far I am) is all about the wide variety of difficult lessons he's learned on the way to mastery of his craft. There are many other books like this, and they tend to be very instructive.

<comment><USER31> This is interesting to me. Would you have any other book recommendations in this vein?

<comment><USER30> _Effortless Mastery_ , by Kenny Werner. _The Music Lesson_ , by Victor Wooten. Both of these are about music, but are really about mastery.

 _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_?

<comment><USER31> Thanks for the recommendations, I've added these to my book list! In exchange, have you seen this [1] report about excellence in competitive swimmers? The lifetime of a swimmer is short and outcomes vary wildly, from local swim meets all the way to the Olympics. It's a great case study on the differences at each level. There should be copies on sci-hub or other online summaries.

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...](https://www.jstor.org/stable/202063?seq=1#page_scan_tab_contents)

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

</comment></comment></comment></comment><comment><USER32> One method I've found, although slightly obscure and more frontend related:

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

</comment><comment><USER33> My advice:

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

</comment><comment><USER34> I love this question, but I would like to extend it a bit. Even though the body of the question the OP asked is about software dev specifically, how do you learn other non-software dev best practices when no one is there to teach you?

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)?

</comment><comment><USER35> It's hard to get "better" at something because it can mean so many things. Describing the attributes that makes you better with MongoDB, APIs, or software development gets you a lot of the way towards learning how to do it.

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.

</comment><comment><USER36> 1\. Make lots of mistakes.

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

<comment><USER37> That really doesn't help. How do you know that what you are doing is a "mistake" if it works?

10K line UserManager classes "work".

That's how you get the "expert beginner".

[https://daedtech.com/how-developers-stop-learning-rise-of- th...](https://daedtech.com/how-developers-stop-learning-rise-of-the-expert- beginner/)

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.

<comment><USER38> _How do you know that what you are doing is a "mistake" if it works?_

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.

<comment><USER39> Funny thing is, if you look at codebases of some opensource projects [1] doing complex and ambitious stuff, written by some real experienced engineers, you'll see the common "dogmas" (don't have long classes, don't have long methods etc. etc.) are not obeyed. And yet, they shipped very complex and successful software. It's almost as if these rules are mostly arbitrary and don't really matter.

[1] I've noticed that in codebases of Apache Spark, Apache Oozie, Apache Cassandra, and Firefox.

<comment><USER38> _It's almost as if these rules are mostly arbitrary and don't really matter._

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_

<comment><USER40> Reminds me of other comments on this subject: one person's best practice is another person's bad practice.

</comment></comment></comment></comment></comment></comment><comment><USER41> I'll follow the pattern here of expressing incredulity on the fact that my personal way of dealing with this is different from everybody else's ;-) Read code. Look around the internet for projects similar to what you are working on. Try to find and fix a bug or two in each. Concentrate on how you feel working on these unfamiliar projects. Was it straightforward to work on it? Was it fun to poke into? Did you feel straight jacketed in your approach? When you submitted the fixes, how was the reaction? Was it easy to get a positive reaction? Did people thank your for your contribution but then rewrite everything you did? Did they tell you that you didn't understand the issue and reject your contribution? These are all big clues on the success (or lack thereof) in the approach taken on those projects.

</comment><comment><USER42> There are a lot of niche slack communities popping up. I've gotten a lot of great insight being a fly on the wall of a couple.

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.

</comment><comment><USER43> My advice would be not to worry about this too much at this phase. A lot of "best practice" is institutional and has to do with how the stack/org/community is structured. There's not a lot that's "best practice" in a vacuum. In terms of stuff that would be considered best practice in a vacuum, you can maybe look at some of the classic stuff like Code Complete, or any of the TDD or pattern books.

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

</comment><comment><USER44> Use Google scholar to find papers on API design. Here's one [https://ai.google/research/pubs/pub32713.pdf](https://ai.google/research/pubs/pub32713.pdf)

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

Check 'cited by' to find more papers

</comment><comment><USER45> \- online curses

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

</comment><comment><USER46> I suggest:

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.

</comment><comment><USER47> There are three ways of learning

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.

</comment><comment><USER48> Just my two cents: learning by "experience" works, but is extremely inefficient, and you don't always get the feedback of your work. You always learn by experience, but you do as much as you can to learn to avoid making mistakes in practice. Compare it to learning to drive: Yes, you learn driving by experience, but you still need driving lessons to avoid getting in accidents.

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.

<comment><USER12> This is a great metaphor.

</comment></comment><comment><USER49> I would start with the book 'Practices of an Agile Developer: Working in the Real World'.

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.

</comment><comment><USER50> Books & projects.

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...](https://github.com/mythicalprogrammer/elixir_genserver_practice)). 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.

</comment><comment><USER51> Been there, done that. Little story time: I co-founded a startup (as technical co-founder obviously) straight out of education, and never really had any mentor. 6 years later, I've certainly done lots of mistake, but no critical one, and I can count on one hand the mistakes that had important consequences.

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.

<comment><USER52> > Or mostly about RPC? Might want to read up about SOAP.

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

Rest is gold.

<comment><USER53> 'Those who do not learn history are doomed to repeat it.'

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

</comment></comment></comment><comment><USER12> I was asking myself this in 2013 and in 2014 I quit my job because of it. I thought [https://www.codementor.io/](https://www.codementor.io/) was going after this problem.

——

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.

</comment><comment><USER38> Create an iterative loop with three major steps in it:

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.

</comment><comment><USER54> Since you are using node, a good first step is to setup ESLint. It will help you stick to a standard and probably teach you new things. That's how I learned about const, let and arrow functions (I think I was using airbnb standards at that time). Otherwise, it will improve the overall consistency of your code.

</comment><comment><USER55> Personally I actually think you will gain a better understanding because you have nobody to teach you.

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.

<comment><USER56> I wouldn't say that... I'll often put in "for next time, look at..." type advice in Pull Requests from more junior coworkers. Sometimes working is more important than ideal.

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.

</comment></comment><comment><USER57> It's a real challenge. You really just need someone to tell you "no, do this, don't do that." A lot of things are just wrong in subtle ways or invisible until you hit a certain scale, so you have no idea.

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.

</comment><comment><USER58> Fail a lot and cry yourself to sleep until you get pretty good at it. Thanks for coming to my TED talk.

</comment><comment><USER59> Conferences.

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.

</comment><comment><USER60> The best place to learn about MongoDB is the MongoDB free e-learning university website: [https://university.mongodb.com](https://university.mongodb.com). You can follow free courses here - MOOC style.

</comment><comment> munk-a Advocate for time, the time you'd spend making those mistakes is going to be a loss on the company compared to convincing your manager (or their manager) to allocate some of that senior dev time to mentorship. This isn't about walking you through tickets step-by-step but make sure that you get smallish tickets in these new areas of tech and ask your co-workers to vet your work (this usually happens in the form of a PR review).

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.

</comment><comment><USER61> Self learning is one thing and being completely on your own without a way to ask specific questions on the daily basis is totally another.

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.

</comment><comment><USER62> Keep things simple and idiomatic. Use dependency injection and hook everything up in main. You should be able to open up your code and understand what's going on just by looking at this setup.

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.

</comment><comment><USER63> Read code reviews of senior developers.

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.

</comment><comment><USER64> Reach outside your company. Genuine appeals for focused help are rarely dismissed.

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.

<comment><USER65> I'm having trouble imagining how to do this. What does it look like? Emailing a friend at another company to ask for code review?

<comment><USER64> I am old fashioned, so I use IM to say things like "Hey, Martin, I'm thinking about ... Does it make sense?"

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.

</comment></comment></comment><comment><USER66> So, avoiding the discussion of what constitutes best practices, it's important to recognize that you don't know everything (which you seem to get), but also identify the things you don't know and learn how to research them enough to handle your task, which is definitely more than Wikipedia but most often you don't need to be an expert in a thing. Unfortunately, if you don't have people around to grade your work, developing a sense of this can be quite hard.

</comment><comment><USER67> By the time things have been reduced to "best practices" the intellectual rush of discovery has been cooked out. If you a still fishing for best practices: experiment, make mistakes, fix, learn how things work, run tests, try things that make sense first, talk through problems with smart friends, and enjoy the fruits of discovery. It is often helpful to find a mentor, someone who can help structure the search for "best practices" and who will give advice.

</comment><comment><USER68> Learn from your own mistakes. But that doesn't scale too well, therefore, learn from other people's mistakes.

\- ex-boss

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

</comment><comment><USER69> you're already doing the right thing by thinking about best practises. your question is pretty vague though, which is probably what invites so many comments about "experience" being the best teacher. just saying to "learn the hard way" is doing you a bit of a disservice though, because there is a ton of material out there!! read it. oreilly my friend. and be sure to share it with your team

</comment><comment> edouard-harris See if you can find someone external to your company to mentor you. Easier said than done, it's true, but most people who are currently employed can find someone in their social graph within one or two degrees of separation that's able and willing.

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.

</comment><comment><USER70> Books. IMO, Books is the best way of aquiring knowledge.

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!

</comment><comment><USER71> I'm in the same boat as a solo developer. I recommend subscribing to Safari Books Online ([https://learning.oreilly.com/](https://learning.oreilly.com/)). As your first action, watch the video series for Clean Code. It's just incredible and has helped me grow as a developer more than any other resource.

</comment><comment><USER72> Talk to your workmates and boss about the advantages of doing regular code reviews. You review their code, they review your code. Nothing too formal or in-depth, best done frequently before additions get too large, but I guess you also don't need to review every since added line.

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

</comment><comment><USER73> Everyone is already piling with sources to learn from, so my biggest advise is avoid falling into the trap of cargo culting and overfollowing the internet echo chamber. Personal experience is worth so much more than reading something from a blog post somewhere, even if that somewhere would really be good information which is not at all such a given

</comment><comment><USER74> "when you have no one to teach you?"

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.

</comment><comment><USER75> Lots of good advice, I will add: revisit your own code from a previous project. Best place to learn about your own habits.

</comment><comment><USER76> Look up node.js best practices at GitHub. It's a great repository with some real nice tips on production ready node.

</comment><comment><USER77> Use a lot of API's to experience the pain points. Read a lot of other peoples source code. For example the code of your dependencies. Learn by failure, but also other peoples failures. Read blog post and articles about what you are doing. Participate in chats and forums. And be persitant and have good confidence.

</comment><comment><USER78> Usually if you are the smartest person in the room it's time to move on to a new job, otherwise you are only hurting yourself especially when you are still in the early stages of your career where you'd want to learn fast.

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

</comment><comment><USER79> There are a lot of articles here on HN explaining problems other people ran into, solutions and best practices. Just keep reading. I read for 30 min every day on new tech and ideas even if I don't use them regularly. Keeps me in the loop and a lot of the ideas and principles are portable to other projects.

</comment><comment><USER80> There is about five to ten books that will be commonly recommended to be a better programmer. Code complete, Smalltalk best practice patterns, clean code etc. You can find lists online. Read a few that seem interesting and at least you will have common ground with many other programmers.

<comment><USER37> Speaking of which, my list:

[https://news.ycombinator.com/item?id=18794561](https://news.ycombinator.com/item?id=18794561)

</comment></comment><comment><USER81> Today's best practices are tomorrow's legacy codebase. Don't get hung up on "doing it right" if your code works & your comfortable with it, i.e it is maintainable and it is reliable.

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.

</comment><comment><USER82> I recommend:

[https://github.com/tallesl/Rich-Hickey- fanclub/blob/master/R...](https://github.com/tallesl/Rich-Hickey- fanclub/blob/master/README.md#talks)

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

</comment><comment><USER83> See if you can work with them to plan your code before you guys write it. And afterwards, if you can do a code review for each other. This is hard in startups but it can avoid a lot of bugs downstream; cuz I'm guessing you don't really have any QA either.

</comment><comment><USER84> Direct your learning by what you need for your work. You can watch videos on the frameworks and tools you're using, read blog posts on issues you might have etc.

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

</comment><comment><USER85> This approach is definitely up for debate but I stay abreast of emerging "best practices" by reading the blogs of the tools I use. I'm a software tester interested in project management and find myself reading Atlassian's QA blog quite a bit.

</comment><comment><USER86> No one to teach you? Google, Udemy, GitHub, YouTube, Dev.to, etc. etc. When I started there was no internet and all I had was a book and 'phone a friend' if I broke something :)

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

</comment><comment> rooam-dev Human evolution at single person scale :)

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!

</comment><comment><USER87> 1\. Reading and learning from other people's work is certainly a good way to learn new approaches. 2\. Learning to measure how your code/application performs will let you test various approaches so you can decide for yourself.

</comment><comment><USER88> Got to relevant industry/community forums or Slack channels, and participate in the discussions. You'd be surprised at how willing people are willing to share insider secrets when you're participating in the community.

</comment><comment><USER89> Go to GitHub and start contributing to open source projects that use the same stack.

</comment><comment><USER90> Read and if possible contribute to an Open Source project you are using everyday.

</comment><comment><USER91> I learned a lot by working on open source projects in my younger days. People were always around on IRC to answer questions, especially when answering my questions got them closer to their own goals for the project.

</comment><comment><USER92> There are a lot of famous books on the subject of best practices: "Code Complete" and "Clean Code" are the first to come to mind, but I'm sure the folks here can recommend others.

<comment><USER93> These are the _timeless_ books and should be required reading

Pragmatic Programmer: [http://amzn.com/020161622X](http://amzn.com/020161622X)

Code Complete 2: [http://amzn.com/0735619670](http://amzn.com/0735619670)

<comment><USER94> Refactoring by Martin Fowler is a great one [https://www.amazon.com/Refactoring-Improving-Existing- Addiso...](https://www.amazon.com/Refactoring-Improving-Existing-Addison- Wesley-Signature/dp/0134757599/)

Design Patterns is also very well known [https://www.amazon.com/Design- Patterns-Elements-Reusable-Obj...](https://www.amazon.com/Design-Patterns- Elements-Reusable-Object-Oriented/dp/0201633612)

</comment></comment></comment><comment><USER95> Best practices is a marketing term. Put it aside. Your problem isn't that you lack some particular practice, but rather that you feel incompetent and inferior. New techniques won't fix that.

</comment><comment><USER96> I sympathize with the situation of having "no one to teach you".

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.

</comment><comment><USER97> I haven't seen this advice yet but follow thought leaders on Twitter. They'll post blogs and offer advice to keep you up-to-date on what the zeitgeist of your lingua franca is.

</comment><comment><USER98> You can always find people to help you. I'm not a node + express specialist but I do a fair share of JS, you can contact me at firstname.lastname@example.com if you want.

</comment><comment><USER99> I did my best ever learning working with a peer who had about the same skill level as me. We grew together and exchanged notes about things we learned.

</comment><comment><USER100> I would say contributing to a popular project would be a good starting point if you want to see the end result of conventions.

</comment><comment><USER101> Look up github repositories that with desirable implementations. Follow people on twitter posting about their experience.

</comment><comment><USER102> Wait until the next engineer, however experienced, inherits your code and he will tell you everything you did wrong.

</comment><comment><USER76> Look up node.js best practices on GitHub. Great repository with a lot of tips for writing production ready node.

</comment><comment><USER103> [https://jsonapi.org/](https://jsonapi.org/)

</comment><comment><USER104> Read engineering blogs, most big companies have it. Follow HN topics Read books Go to conferences

</comment><comment><USER105> Some practical things that have helped me, by no means an expert:

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

</comment><comment><USER106> Try to contribute to open source projects

</comment><comment><USER107> Join a programming Slack group.

</comment><comment><USER108> This is something that can be difficult to learn even if you've been working in the industry (lord knows we've all seen awful practices at various companies in our career).

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/](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.

</comment><comment><USER109> Use common sense and think through

</comment><comment><USER110> > 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?

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.

</comment><comment><USER111> Blog posts other developers make detailing the way they've built a particular project have helped me gain some perspective when looking to understand how people are working in a particular stack. Learning from other projects is good for understanding how people are using contemporary tools. Github is also a great source for this, you can search with those tags to find relevant projects. As for software engineering in general, there is more academic materials which cover various methodologies ( you can just search software engineering and find many resources ). There are so many resources out there; I don't personally have a systematic way of navigating it. Once I find a good resource, I tend to look at what else the author has done and who else is connected to that author and then I walk around what that social circle's body of work, picking up various things. Finding the sages in a particular area, finding out who really knows about the area I'm studying at the moment, then learning from them... all starting from Google searches and some sleuthing.

<comment><USER112> _Blog posts other developers make detailing the way they 've built a particular project_

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.

<comment><USER111> Yes, good point. Usually you can filter blogs by reading the comments and seeing the reception it got as well as the popularity. If it is an open source project, you can see the stars on GH and read through the issues on the repo to further filter. Books get outdated very quickly for modern tech stacks. I would recommend them for the fundamentals, but not contemporary stuff. You obviously have to do your due diligence here. Researching the author is also important obviously if you are going to truly heed their advice.

</comment></comment></comment><comment><USER113> I recommend participating, daily, in communities, particularly ##programming or #python (if that's the language you're learning) on Freenode.

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.

</comment><comment><USER114> Stackoverflow. No joke. I'm not saying look up stuff on stack. I'm saying literally ask your expert level questions on the site. The wealth of experts willing to answer obscure questions is incredible.</comment>


How Software Companies Die (1997) - <AUTHOR> http://www.cs.cmu.edu/~chuck/jokepg/joke_19970213_01.txt

<comment><USER2> It is rare for an engineering founder to assert leadership for an extended period of time, but when it happens, amazing things can follow. Microsoft, Oracle, Facebook, Github, SAP all come to mind.

</comment><comment><USER3> Today, HN has been full of stories that make me sad about being a software guy. Maybe the only way is to work in early stage startups, moving on after the managers roll in and your day is full of meetings about new reorganization.

</comment><comment><USER4> I hope other board of directors will learn from Marissa Mayer being hired as the CEO of Yahoo.</comment>


HiredBox – Ask the right questions in your technical interviews - <AUTHOR> http://www.hiredbox.com/ <comment><USER2> Who are these industry leaders who only price their time at $60 to $120 per hour? (Certainly not anyone who's read the advice by tptacek, patio11, et al. about consulting.)

<comment><AUTHOR> Very interesting to see all these comments about pricing. Our introductory prices were based off similar services where you chat with an experienced dev for an hour for help with your code, etc.

<comment><USER3> Are any of those services any good? People who can code well enough to improve a design after a 1-hour phone call generally aren't incentivized to spend an hour on the phone talking to random developers.

</comment></comment></comment><comment><USER4> I would be interested to read more on their interviewing process since every "interview" thread on HN receives triple digit comments and there doesn't appear to be any consensus on how best to interview candidates.

</comment><comment><USER5> $60/slot from someone that is likely making 5-10X that an hour in their day job via base salary (not including stock grants) is a bit ludicrous. I like the idea, but you really have to charge what the time of these people is worth. On one side, this pricing will likely only serve to further the interest in the product from a customer. On the other side, you may actually get real significant talent onto the platform, not people who are trying to run a consulting business.

How about this - pay the expert a portion of the salary. The $/hour would make a bit more sense, and the 'experts' aren't going to laugh at how overrated the recruiter is in the process.

<comment><USER6> Please. Who, in tech, is making $300 to $600 an hour "base salary"? Pretty much nobody other than a handful of VPs and CEOs. None of which are likely able to to do a real technical interview anyway.

<comment><USER5> $300 constitutes, before taxes, around $550k. This is not unheard of for senior / director level product management or engineering hires at some large tech firms. Do not believe what you read on glassdoor. There are plenty of Googlers that are making around $1M in salary in these types of roles.

</comment></comment></comment><comment><USER7> Sounds like a cool concept. I would want to know how you address the obvious conflict of interest issue since many of these experts presumably would be hiring (or have friends who are hiring) as well.

</comment><comment><USER8> Despite all the negativity around pricing I think this is an excellent idea.

I would certainly do frontend coding tests with people for say $100 per hour. From a beach. In Bali.

</comment><comment><USER9> Hard to say if your service is valuable without some references but the pricing looks quite attractive if your people really are qualified. I know job titles look good but some of the smartest people I've met haven't beent CTOs or founders, they've been senior developed who have years of experience.

Nevertheless good luck and I think this is a great idea.

<comment><AUTHOR> Thanks for the comment. True about the titles - the people we work with have years of experience in industry, and setting out to build their own companies. They've had to recruit along the way too and so know the struggles of finding good candidates, especially when expanding and having to interview for new roles. Our process starts with a chat so that we get to know the client's requirements and they get to know us before going forward.

</comment></comment><comment><USER10> as someone who been a sysadmin/devops engineer for 15 or so years now, I think you should add that as an option. I've interviewed for at least 10-15 first devops hires and all the interviews technically were a joke. Comparing them to interviews with at least one other devops engineer in house that is.

</comment><comment><USER11> I am curious to see what people should expect as the output of the service.

Does the interviewer return back a single "hire/no hire" bit or is there a more detailed assessment of the candidate's strengths/weaknesses within the topics covered?

</comment><comment><USER12> There is a lot interesting stuff going on in the hiring space, I like that this has a human touch - uber-for interviewers.

have you thought of working with something like [https://clarity.fm/](https://clarity.fm/)?

</comment><comment><USER13> I'd certainly be interested in having myself interviewed at the listed price. I think I'd also have someone who I didn't want to hire be interviewed to see how the results compare.

At the price listed it certainly seems viable.

</comment><comment><USER14> Has anyone had any experience of using services like this? I struggle to interview for completely new roles when we first establish them, and could see this being useful in those scenarios.

</comment><comment><USER15> perhaps it's how I am, but if I'm not interviewing with people who are part of the company, how am I supposed to make judgements about whether I want to work with these people?

<comment><USER16> It's a technical interview to assess your technical knowledge. The idea is you'd have another interview with your boss about your teamworking skills and similar rubbish.

I can actually see a need for this, but they need to get more experts than "our mates from nearby startups and their parents."

Also the subjects they've listed are all for programming topics when I doubt you're going to be in the situation of not already having some in house experts. They need much more niche subjects.</comment></comment>