People often struggle with this starting out but being a developer in an org is not just coding. It’s also teamwork, project planning, and mentorship.

Realistically spikes should be done beforehand reducing the estimate to worst case x 1.3~

Worst case x 1.5 to account for unknowns and spikes. Based on average task previously. Make sure to break down as granular as applicable.

@sunfishcc unfortunately only runtime :)

@Robinha haha good catch, thank you. We should have a meeting to discuss your findings.

@irene unless you are doing any gpu (cuda) work which is most definitely not imperative.

Again being someone who codes JS almost daily for a living, I have yet to really feel it as inelegant any more than other languages I’ve had the pleasure of making acquaintance with.

But to each their own.

@irene weak typing agreed. But all of these are present in n-number of languages :) I think JS gets needlessly bashed. When used properly it’s great (much like any other tool).

Although I’m still impartial to the idea of replacing everything with erlang ;)

@irene it’s logical enough. What jumps out at you?

So write some docs saying exactly that...

@billgates first sign of a junior / intermediate dev: Overconfidence.

Prettier auto fixes this stuff up for me.

Starving musician.

@Pseudonymous here every few days you’ll have someone complaining about JS due to not understanding one of the language fundamentals.

On medium people constantly complain that there are too many libraries and how they “are not better than using vanilla”.

People complaining that Scala syntax is too confusing and therefore it’s shit, that php is a shitty language because of the shit code that other developers produced. People bitching about java being verbose despite not understanding what function that verbosity plays.

I can go on and on :p

@devRB13 for sure. I agree. The Op of the screenshot above doesn’t seem to.

@devRB13 I’d wager that if most of your business logic is on the dB side, something is wrong. But I digress, testing whether unit or integration is mandatory for a project that’s bigger than 1 dev imo.

@host127001 in addition to @glinkis comment, if you use flow or typescript then your ide can be even more helpful.

Excuses for shoddy coding practices.

How is that a JS fault? Try writing to stout and then blame the tooling... :p

While I feel your pain, theory is important.

@olback allows the build configuration to be stored in scm, ensuring reproducibility and not requiring each developer working on it to do this manual process.

Also opens door to automating the build / deployment pipeline saving time in the long run.

why not just use webpack or any other build tool?

Tarball it first :)

Instagram :)

The bigger the project the larger the variance I've noticed. Recently completed a 3 month project in 4 months.

Dev error rather than client error in this case imo

What's the actual pronunciation? I've been saying it "baybel" as per the biblical story.

Rmrfer brings up a great point, make sure to come up with a good mvp, don't overthink and allow scope creep. If mvp can be completed as a bite-sized chunk, then you'll have more determination to keep working on the idea compared to spending months on something that never reaches the prototype phase.

Today I saw: "es6, react, ember, angular"

Tip #694: Always try to leave a paper trail.

Next up, tracking number of lines added. :p