loading...

Tell me an unpopular software opinion

ben profile image Ben Halpern ・1 min read

I tweeted this yesterday and the response was not good.

Tell me your unpopular opinion. Lighthearted only.

Discussion

pic
Editor guide
Collapse
gypsydave5 profile image
David Wickes

CSS and HTML are sufficient to build 99% of all websites.

Collapse
bhupesh profile image
Bhupesh Varshney 👾

Add a little bit of Vanilla JS. that's it

Collapse
gypsydave5 profile image
David Wickes

Like the sprinkles on a cake... 👍

Collapse
loujaybee profile image
Lou — Cloud Engineer

OH DEAR LORD, YES.

Collapse
jasonelkin profile image
Jason Elkin

Your web server is coded in HTML and CSS? How does that work? 😜

Collapse
thomasferro profile image
Thomas Ferro

David was talking about web*sites* ;)

Thread Thread
jasonelkin profile image
Jason Elkin

Indeed, a server is the difference between a text file (containing HTML or otherwise) and a web*site*.

Collapse
yujiri8 profile image
Ryan Westlund

I can't do a comment system with just that.

Collapse
gypsydave5 profile image
David Wickes

Yes you can 😁 - think of it as a forum.

Thread Thread
yujiri8 profile image
Ryan Westlund

I can't do a forum with just CSS and HTML...

Thread Thread
raghavmisra profile image
Raghav Misra

I could, use <form> and make the magic happen on your backend/server.

Thread Thread
yujiri8 profile image
Ryan Westlund

Technically but that sucks. You have to refresh the page every time they click something. You can't even do a preview without refreshing. You can't solve the comment box resize problem (<textarea> doesn't resize by default), but it only takes a small amount of JS to fix it.

Thread Thread
yujiri8 profile image
Ryan Westlund

Like I'm a big fan of minimalism, but I advocate Javascript when it allows a significant UX improvement that's impossible without it.

Thread Thread
raghavmisra profile image
Raghav Misra

Of course, I'd never do it in practice (I'd judge anyone who would). I was only trying to prove the unpopular opinion. :D

Thread Thread
gypsydave5 profile image
David Wickes

I really recommend both of you disabling JS in your browser and opening Gmail up to see what can be done.

Thread Thread
raghavmisra profile image
Raghav Misra

Exactly!

Collapse
sebastiangperez profile image
Sebastiangperez

True , maybe a javascript and json file reading for content and thats it you dont need a fancy stuff.

Collapse
s_aitchison profile image
Suzanne Aitchison (she/her)

Super high coverage testing is sometimes a waste of time 😬

Collapse
bpedroza profile image
Bryan

A counter unpopular opinion: Everyone should do at least one project with 100% coverage to understand why some tests are better left unwritten.

Collapse
s_aitchison profile image
Suzanne Aitchison (she/her)

Ooh I like this! But don't think I could inflict that on anyone 🙈

Collapse
dwd profile image
Dave Cridland

Don't forget to do tests for the tests.

Collapse
gypsydave5 profile image
David Wickes

💯 coverage is usually an indicator of highly coupled testing, which leads to very fragile tests, which leads to the tests being turned off...

Which leads to anger, anger leads to hate, and hate leads to suffering.

Collapse
ben profile image
Ben Halpern Author

For every metric, there is an equal and opposite metric.

Test coverage is good to know and track, but it can hide problems if it isn't a factor considered alongside a lot of principles and qualitative decision making.

Collapse
s_aitchison profile image
Suzanne Aitchison (she/her)

Yes exactly; test coverage isn't the goal in itself and I think sometimes focusing too much on a percentage coverage is a distraction from creating an actual robust pipeline.

See also: snapshot testing in the frontend. Very easy to achieve close to 100% coverage with tests that are easily ignored and overwritten when they fail 🙄

Collapse
vulpcod3z profile image
vulpz

Who writes the tests to test the tests?? 😵

Collapse
mike_hasarms profile image
Mike Healy

Coast guard.

Thread Thread
jgaskins profile image
Collapse
dwilmer profile image
Daan Wilmer

Mutation testing

Collapse
adam_cyclones profile image
Adam Crockett

100% coverage of low quality tests is so much worse than 20% critical tests.

Collapse
patryktech profile image
Patryk

sometimes

Many, many times.

That said, if you are publishing libraries that are meant to be reused (e.g. on PyPI, or NPM), 100% is often a good idea.

Collapse
ankitbeniwal profile image
Ankit Beniwal 🙂

Full Stack Devs really exist.

Collapse
lukeshiru profile image
▲ LUKE知る

Every "full-stack" I knew is either great with front and bad with back, or vice versa. But this post is about unpopular opinions, so I guess is ok 🤣

Collapse
scott_yeatts profile image
Scott Yeatts

This is semi-accurate. I'm specialized in front-end, but have built a TON on the backend.

HOWEVER, I don't look at a backend specialist and say "Anything you can do, I can do", I simply approach every conversation with humility and acceptance that there may be a better approach, and I can't possibly know everything there is to know about all aspects of code.

I'm not bad at backend. But I can realistically assess that while I might be able to architect a cutting-edge front-end with all the bells and whistles, I can simply do an adequate job on the backend. That said, I have had the experience of writing a breadth-first sorting algorithm for a backend implementation covering millions of nodes that completed in 5 minutes vs the previous 6 hours (written by a backend specialist who I would say is VERY good)... so I definitely wouldn't say I'm BAD at the backend...

As a community we need to embrace the fact that there are universal coding patterns that can be applied on the frontend and backend. While I might specialize in tools for the frontend, that doesn't prevent me from using those patterns in work on a backend.

Thread Thread
jsbeaulieu profile image
Jean-Sébastien Beaulieu

This is what I'd call "experience" though. How long have you been working in the field?

I do agree with you, though. People will have to come to terms with the fact that any decent web developer can learn most parts of the stack just fine with some effort and a tiny bit of interest.

Thread Thread
scott_yeatts profile image
Scott Yeatts

Define "working" ROFL (Kidding)

Getting paid? A little over 10 years now.

But writing web code? Let's just say I remember writing code at a time when CSS didn't exist.

And absolutely it takes experience. I would look sideways at someone calling themselves a "Full Stack Engineer" on the first day of their first job without some significant background information haha.

Thread Thread
jsbeaulieu profile image
Jean-Sébastien Beaulieu

I'm 3 years in, have worked on production environments maintaining and developing PHP/Node.js back-ends as well as React/Vue front-ends, and CI/CD infrastructures...

I'm still having a lot of trouble calling myself "full-stack". I'm way too junior to pretend I know both well enough.

Thread Thread
scott_yeatts profile image
Scott Yeatts

First: Sounds pretty "Full Stack" to me. Second, make sure you have a specialty that you feel like is your "go-to" (Front-end, back-end... and even though "DevOps" is a mindset, it CAN be a specialty too).

If you've got that, but you wouldn't "little Bobby Tables" if you touched another piece of the stack, then you're full-stack.

You DO need a realistic assessment of your own skills. If you're mid-level in the front, but junior in the back, be honest about it and ask for mentorship and guidance from a senior backend engineer, but don't be afraid to pickup those stories either :D

xkcd.com/327/

Thread Thread
jsbeaulieu profile image
Jean-Sébastien Beaulieu

Pretty much the opposite situation for me! I'm primarily back-end, but learned JS, then React/Vue, then CSS out of sheer necessity, then realized I wasn't half as bad as I thought I was at it. I still suck at layout, especially when responsive, but I'm getting decent at scaling things in mostly sensical ways.

I'm probably getting to mid-level in back-end at this point, maybe? And I learned DevOps-y stuff by scaling up my team's growing architecture past their FTP and manual CRON jobs on a single VM.

Collapse
daniel13rady profile image
Daniel Brady

What is a full stack dev? A "jack of all trades"?

Collapse
peiche profile image
Paul

Yes, we exist. I design, write markup, styles, and handle back-end code and design database models.

Thread Thread
jasonelkin profile image
Jason Elkin

But can you solder? 😜

One of the fun games to play with people who call themselves full-stack devs is to see just how "full" their stack is. So often it's just a bit of JS and PHP.

Thread Thread
ankitbeniwal profile image
Ankit Beniwal 🙂

I can solder 😂😂

Exactly, I have also seen bad examples of full stack. But that doesn't change the fact.

Collapse
daniel13rady profile image
Daniel Brady

I ask because I think people use the terms "front-end developer," "back-end developer," "full-stack developer," "Java developer," etc. in different ways.

Sometimes an "XYZ developer" term seems to describe the skill set possessed by a developer, and other times it is used to describe the specialization area of a developer.

When talking about skill sets, the term "full-stack" makes some sense to me: it emphasizes that a developer has learned a little about a lot and is comfortable diving deeper anywhere, including new territory.

But when talking about focus areas or areas of specialization, I think the term "full-stack" can be confusing: it seems to say "I'm good at everything," but a) that's not true, and b) every tech stack is different.

Thread Thread
daniel13rady profile image
Daniel Brady

Also, the terms "front-end" and "back-end" refer to different things depending on if we're talking about web development or not.

Personally, the only modifier I tend to use with the terms "developer" and "engineer" is "software." Anything more feels like I'm putting myself in a box, and it might be hard to get out of later on.

"I'm a software engineer with ___ experience using ___ technologies, and I want to learn more about ___ by working on ___." More verbose, perhaps, but also a more accurate characterization of myself.

Thread Thread
jasonelkin profile image
Jason Elkin

I think you've hit the nail on the head. Web Devs too quickly silo themselves into front or back-end and limit themselves to understanding only part of the product they're working on.

So often I've seen features implemented in the wrong place in the stack. Not because the Dev was bad, because they didn't want to learn a language on the "other side" of the stack.

This should be more than doable for an average Dev (being multilingual is, after all, a thing) but for some reason the REST API seems to represent a cultural divide between the front-enders and back-enders and us full-stack Devs are viewed suspiciously by both.

SOLID, TDD, Agile, all apply to both "sides" of the stack. It's certainly possible to be a good Dev on both sides - so long as you don't measure being a good dev as simply someone who can remember all the native functions in that language.

Collapse
jsbeaulieu profile image
Jean-Sébastien Beaulieu

I think that while they do exist, they all tend to have a specialty and, more importantly, relatively important shortcomings. I've yet to meet an actual full-stack that doesn't suck at one part of the stack, be it CSS, server configuration, DevOps, whatever.

Myself included. I suck at doing responsive layouts.

Collapse
piq9117 profile image
Ken Aguilar

This is not so uncommon. There are a lot of people who can program the client all the way to Assembly. The question is, is this an efficient way to work in a project?

Collapse
jsbeaulieu profile image
Jean-Sébastien Beaulieu

Depends.

If your team and project scopes are small, hiring "full-stacks" make sense. There simply wouldn't be enough work for a full-time front-end developer in many places.

However, I've also seen places hiring a full-stack in hopes or getting rid of the need for an actual front-end developer for their product. Or hiring front-end devs who can use Firebase in hopes they won't need a back-end.

This rarely works, and when it does, it does quite poorly.

Collapse
msarit profile image
Arit Amana

Devs can build their portfolios on WordPress

Collapse
ben profile image
Ben Halpern Author

This is a great one.

Wordpress isn't exactly an "elegant solution" these days, but it is a hardened one with basically every use case imaginable covered. Any user-facing flaws can be overcome with tooling and config, same as any comparable software.

It's also very useful to learn Wordpress. The company behind Wordpress just raised another $300m. The software isn't going anywhere any time soon.

Collapse
paramharrison profile image
Paramanantham Harrison

True Ben.
Headless Wordpress with Gatsby kind of well optimised frontend will be a killer combo for mid sized projects

Use cases,

  • content websites
  • e-commerce websites
Thread Thread
jkhaui profile image
Jordan Lee

Can second this. Been building a full-stack app for a few months now using WP as the backend + GraphQL API and React Frontend. Also use some serverless functions to supplement functionality that can't be done in WP.

It's been amazing because as a single dev, I can work on what would otherwise be a huge/impossible project by leveraging WPs' CMS, authentication features and plugins.

The only thing slowing me down is the WordPress GraphQL ecosystem is still almost non-existent

Thread Thread
chris_beef profile image
Chris B

I'm going to be looking into Gatsby and next.js this year. One question - how do you handle updates on Gatsby when a post or something else is updated in WordPress? Do you have a hook/action that is triggered and posts to gatsby to run a new build?

Collapse
0xdonut profile image
Mr F.

I used wordpress once in 2003 but I haven't built a single wordpress site ever since!

I recognise what people have done with it, and it's maturity as a platform, but I count myself lucky!

Collapse
georgeoffley profile image
George Offley

I've had one on WP for years now. I'm switching to hosting everything on a GitHub pages site. It's just far easier to maintain with little effort. Helps focus on writing rather than messing with a WP set up.

Collapse
jvarness profile image
Jake Varness

Too many plugins, not enough code I can modify without fear.

Collapse
piq9117 profile image
Ken Aguilar

Mine is even more primitive. I use a static site generator. Lol

Collapse
bernardbaker profile image
Bernard Baker

It's 5pm I want to go home.

Collapse
aumayeung profile image
John Au-Yeung

Yea. People are working themselves hard. I think some people are worried about their prospects or they really love their job.

Collapse
bernardbaker profile image
Bernard Baker

It would definitely be the prospects. I've worked with companies that do have a good balance though.

Thread Thread
aumayeung profile image
John Au-Yeung

Yea. There are nice ones. Just that there're more bad ones.

The nice ones probably have more competition and don't need to hire as often since the turnover would be low.

Thread Thread
bernardbaker profile image
Bernard Baker

That's true. I got an email from a company that I interviewed with a year ago. Before I set up an e-commerce website. And they have all three roles open again. Turn over maybe... What do you think?

Thread Thread
aumayeung profile image
John Au-Yeung

I don't think most companies need employees that badly. They just want more for extra growth.

They aren't closing without them.

Thread Thread
bernardbaker profile image
Bernard Baker

That's a good point. Could you explain in more detail?

Thread Thread
aumayeung profile image
John Au-Yeung

I mean they can still operate without hiring more people.

Just that they might not have as much output.

Thread Thread
bernardbaker profile image
Bernard Baker

Oh I see. That makes sense. Thanks for explaining that in more detail.

Collapse
georgeoffley profile image
George Offley

My boss makes a point of telling us he doesn't pay overtime. When I first started I was staying until 6-8 PM. Absolutely not worth it.

Collapse
aumayeung profile image
John Au-Yeung

Not paying overtime is pretty normal. But staying that late definitely not normal

Collapse
bernardbaker profile image
Bernard Baker

But did your contract have that clause which states working extra hours to get the work done?

Collapse
daniel13rady profile image
Daniel Brady

JavaScript is well-designed: most of us simply don't use it effectively and too frequently blame the tool for our problems.

Collapse
somedood profile image
Basti Ortiz (Some Dood)

It honestly irks me a lot how people cite the infamous 0.1 + 0.2 floating point arithmetic error as a justification to ostracize JavaScript (even though most programming languages suffer from this issue as well by virtue of floating point limitations).

Like, seriously? Are tiny nuances really that evil so as to dismiss the programming language altogether? No, right? Python suffers from the same error, but is nonetheless one of the most loved languages out there.

You are definitely correct about people not using it effectively. When people write arguments against the languages, it's always because they don't use it right, as in non-"Pythonic" code for Python.

Collapse
patarapolw profile image
Pacharapol Withayasakpunt

No, I would cite -- github.com/aemkei/jsfuck

Most importantly, [1, 2] + [3, 4] that I learnt from Python. I know that there is .concat() and spread operator, but still...

Another thing is var hoisting, but it can be made understand, really.

Thread Thread
ashoutinthevoid profile image
Full Name

I hope I'm misunderstanding, but this style of example "learnt from Python" always puzzles me. Specifically, why do devs expect things to work the way they do in some other language, rather than learning the constructs in the language theyre presently working in?

Thread Thread
patarapolw profile image
Pacharapol Withayasakpunt

I do suppose that the language should be failsafe. Even TypeScript doesn't warn., nor throws an error. Even Python is safer. TypeScript is partly safer, and some part more dangerous than Python, due to JavaScript-based.

RTFM, partly, is OK. But reading the whole EMCA specification is crazy.

Also, I cannot expect tutorials to teach everything.

I also expect the language to be "guessable" rather than being told to do so. Otherwise, throw an error early.

Productivity doesn't wait for you to finish learning...

But knowing additional paradigms might be helpful. Knowledge should add-on rather than replace.

Still, end-in-end, I love JavaScript (not even saying TS), more than Python.

Collapse
greenroommate profile image
Haris Secic

Although it was designed in 10 days (in a way) it is quite simple and good enough I would agree. I just would never use it for backend as I prefer type safety and having some thread control. Dynamic typing and such things could be "shoot yourself in the foot" for some devs and then they blame the tool.

Collapse
pixelgoo profile image
Anton Melnyk

Agree, JS is a simple, productive and elegant language with a great ecosystem.

Collapse
jsbeaulieu profile image
Jean-Sébastien Beaulieu

I was following you until "great ecosystem". The whole node_modules thing is mostly a house of cards waiting for the right gust of wind to make everything fall apart, and most of the tooling is mostly over-engineered reinventions of existing tools.

But I really like using the language. It's fun to write in.

Collapse
lukewestby profile image
Luke Westby

IMO the premise that most users don't use it effectively disproves the assertion that it is well-designed. To me, a language that is well-designed is easy to use effectively by default, and so most people would. I like JavaScript because the platform runs in so many places and there are so many different things I can do with it. This is ultimately not a consequence of good language design, though.

Collapse
daniel13rady profile image
Daniel Brady

I like JavaScript because the platform runs in so many places and there are so many different things I can do with it. This is ultimately not a consequence of good language design, though.

I would amend that it to "popularity and versatility are not necessarily a consequence of good language design." 👍

To me, a language that is well-designed is easy to use effectively by default, and so most people would.

I suppose we should come up with a definition of "effective use" for this discussion before we dive too far and realize we're not talking about the same things. 🤓

When it comes to effective use, programming languages are quite similar to natural languages: it's all about communication. How well can you say the right thing?

One of the key differences between natural language and programming language, though, involves the audience: natural languages meant to be read by humans, but programming languages are are meant to be read by humans and computers.

So effective use of JavaScript is a question of how well you can balance what you say, such that it is right (for some, and possibly different, definitions of 'right') for both the readers of your code and the machine that eventually executes it.

To be able to find this balance, and communicate effectively with JavaScript, you need to understand the impact saying certain things in certain ways has on both humans and machines.

Language design definitely influences how challenging this process is, and there are some features of JavaScript (some present in the original design, some recent additions of ES6) that make this process harder than it needs to be, but not enough to make me feel it deserves the amount of flak it receives from our community.

Collapse
aumayeung profile image
John Au-Yeung

I think this is true after ES6 when JavaScript has all the syntactic sugar that other languages like Ruby has.

Also whoever designed it actually thought about what they're changing before actually making the changes.

Collapse
juankruiz profile image
Juan Carlos Ruiz Pacheco

POC are likely the first production release

¯\(ツ)

Collapse
daniel13rady profile image
Daniel Brady

Sad but true. I haven't been in the game long, but I feel like the whole "move fast, break things" mantra is often interpreted as "ship your prototypes."

Collapse
oksoimdave profile image
dave medlock 🧔🏻

Most software products I’ve seen have at least one feature that just screams “we have a demo on Monday, can you code this over the weekend?” And then that’s what goes to prod because there’s another demo on Friday for some other feature.

Collapse
saschadev profile image
Der Sascha

Haha yes

"we have a poc, so the Software is already complete. There is only some logic missing!"

Collapse
greenroommate profile image
Haris Secic

learned this the hard way

Collapse
kiszkielisa profile image
Artur ⚡ Kiszkielis

I would love to hear about your experience in this area.

Thread Thread
greenroommate profile image
Haris Secic

Well latest one was like build this and that and we need demo up in 3 months. Next thing you know always new feature requests and as a must. After that they started talking about release in another 6 months and I was like heeelllll no. They agreed to build prototype and then rewrite the whole thing but I'm sure they think well it's only bug fixing and optimizing. The code is impossible to maintain so hope they understood last time what rewrite means

Collapse
elgoorf profile image
Hussein Duvigneau

Man I think I just found my support group 😢

Collapse
phm200 profile image
Peter Miller

Scalability can be a premature optimization

Collapse
equinusocio profile image
Mattia Astorino

It is, always.

Collapse
adam_cyclones profile image
Adam Crockett

Don't need it, yet doesn't come into it.

Collapse
bretthancox profile image
bretthancox

Agile is rarely implemented properly. It usually ends up as shorter timeframe waterfall with less documentation.

Collapse
adam_cyclones profile image
Adam Crockett

That's just true, not unpopular, just not talked about.

Collapse
stephanie profile image
Stephanie Handsteiner

I guess, that's not that unpopular.

Some “do agile“ because they're trying to come across hip, but once you look inside it's (like you said) plain old waterfall in biweekly sprints.

Collapse
laurenclark profile image
Lauren Clark

I've started asking in depth about user stories, effort/story points, on time deploys vs overtime hours in interviews and literally every company, even large blue chips are stumbling on it. They don't know their process, they think user stories are a waste of time. But then you ship the feature and everyone is all "damn we can't do X" sigh

Collapse
greenroommate profile image
Haris Secic

And called incorrectly. We do Agile is like saying We do Green. Maybe Agile Methodologies?

Collapse
oksoimdave profile image
dave medlock 🧔🏻

I call it FrAgile because the Agile pieces tend to fall apart pretty easily and then it’s just a poorly planned Waterfall project...

Collapse
tomhermans profile image
tom hermans

Oh yes, wonderfully articulated

Collapse
dougblackjr profile image
Doug Black

OMG, you are 100% correct.

Collapse
ryansmith profile image
Ryan Smith

Basic for loops in JavaScript are fine.

Collapse
sesamestrong profile image
Sesamestrong

Depends what you're using then for. For performing operations on every element of an array or object, Array.prototype.map is really nice. But I definitely agree that for loops as opposed to Array.prototype.map, reduce and for each are never really bad; they're just sometimes not the best.

Collapse
karfau profile image
Christian Bewernitz

As soon as you need to have async code in your forEach callback you need to switch your code to the for loop again. So if there is any chance this might happen, pick it right away...

Thread Thread
diegomgar profile image
Dieg Oto

Nope, you can Promise.all()

Thread Thread
karfau profile image
Christian Bewernitz

How, .forEach doesn't collect the returned value, you would need to switch to .map and there are quite some cases where you don't want to fire all of these things "at once".

Thread Thread
sesamestrong profile image
Sesamestrong

Then you can use await and Array.prototype.reduce. It sounds a bit awkward but is actually straightforward.

Thread Thread
karfau profile image
Christian Bewernitz

I'm not sure I get your point (or whether you got mine), so I'll put some code:

Independent of using map or reduce to iterate over an array, the "aaync callback" will return the promise immediately for every item.
(Even the function that contains the await Promise.all will immediately return with a promise, of course)

The implication is that you can not run those async actions in a sequence using the methods provided by Array.protype.

Meaning urls.map(fetch) is the same as urls.map(async (url) => await fetch(url)) and it's not different from using reduce to create that Array of Promises.

But

for (const url of urls) {
  await fetch(url)
}

Will only trigger the second fetch after the first one is done.

I have had plenty of experience where servers have blocked to many simultaneous requests, so it's worth considering the impact the code can have.

(If that's not clear I'm willing to take the time to write a post about it.)

Collapse
jsbeaulieu profile image
Jean-Sébastien Beaulieu

I really don't like seeing people using .map for things not returning a new array. The whole concept of "mapping" comes from functional languages, or even higher, from mathematics, and always have been about "mapping" one set (your input) to another (the returned array). Discarding the output and using map as a glorified for loop makes the intention unclear.

Collapse
lukeshiru profile image
▲ LUKE知る

TypeScript is one of the best things that happened to web development in the last few years.

PS: I know this opinion is not really unpopular. But I also know that the hardcore JS devs get really tilted with this opinion 🤣

Collapse
patarapolw profile image
Pacharapol Withayasakpunt

To me, TypeScript is just like Babel JavaScript with typing. You can always cast to any, or // @ts-ignore. And, the configuration with tsconfig.json is relatively easy. Nowadays, I use ESLint as well, so it gets a little complex.

It is the best "dynamic" typing language IMO, but not strict enough to compare with static typing. Still, being partly dynamic can be massively helpful.

Collapse
lukeshiru profile image
▲ LUKE知る

Agree, if you want strictly typed, you can go and use other alternatives. TS is just optional typing in top of JS. What tilts me a little is when JS devs throw shade to TS because is "useless" and they use any for everything 🤣

Thread Thread
denisinvader profile image
Mikhail Panichev

It becomes less optional when it turns into a standard

I mean, almost every popular project (package) use it and even I really don't like it, I can't ignore ts anymore

Collapse
ashoutinthevoid profile image
Full Name

I have no qualms with TypeScript, but I'll admit i tilted a bit when i interviewed a .net dev whose reasons for using Typescript amounted to "i dont want to learn anything beyond classical inheritance and imperative programming".

Typing options are a great addition to js, it just saddens me when they're used in place of learning the language and the paradigms it offers.

Collapse
lukeshiru profile image
▲ LUKE知る

Believe me, as a TS dev if another developer gave me that as a justification for using TS, I would get tilted as well. TS is a nice addition to JS, but not a replacement. In order to be a good TS developer, you need to be a good JS developer. TS is still just JS with types.

Collapse
diegomgar profile image
Dieg Oto

I like ts a lot, specially with a high configuration of tslint when the team are huge. It never where so easy to team code.

Collapse
jvarness profile image
Jake Varness

I feel so meh about TypeScript lol.

Collapse
samuelblickle profile image
Samuel Blickle
  1. PHP isn't dead and it won't die any time soon.

  2. JavaScript doesn't suck, but a lot of JavaScript developers do.

Collapse
jsbeaulieu profile image
Jean-Sébastien Beaulieu

PHP is definitely not leaving any time soon. It's still the easiest way to deploy a functioning website. Traditional hosts are not the sexiest thing in the world anymore, but they're still running strong. Guess why? Push one index.php file through their web FTP interface (urgh) and you're on the internet.

Collapse
adam_cyclones profile image
Adam Crockett

Burn! Okay how you measure your skill against others, thats nothing to do with languages what so ever. What do you measure 'a lot' as and 'bad' as?

Collapse
samuelblickle profile image
Samuel Blickle

how you measure your skill against others

I don't. To be honest, I would count myself in on devs who suck at JavaScript.

But I think JavaScript gets shamed a lot not because something's wrong with how the language works, but because many users expect it to work in a different way than it actually does.
Some devs come to JS and see the syntax, thinking "Yep, I know C (or C++ or Java or some other language) - I can work with that too.". And then they skip learning it as a new language and instead start using it straight away. But then something doesn't go exactly as they expected it to and they jump on the JS shaming train.

Thread Thread
adam_cyclones profile image
Adam Crockett

For me I started my career in the front end, it got to the point where I wanted more. More than node, more than typescript. Knowledge of programming in general is my goal, my first dip into another language was lua, not syntactically similar just a really interesting simple scripting language, that has deep ties within C, I then tried to tape node and lua together with WebAssembly and c++ because why not. It's true that I am accustomed to C style dialects, but it's also true that I have never had such expectations that everything is like JavaScript. I don't think I have met anyone who has had this expectation, but in my bubble all the developers in our team are full stack with a strong lean towards whatever.

I believe in learning programing concepts not languages, to do this I have delved in to a number of backend languages which I am starting to loose count, (being good at a language was not the point, learning was) Most recently returning to Rust, I find this language is outstanding.

I have not yet taken a stab at PHP but I have wrote a few posts about my shameful predudice against it and why I should give it a chance because honestly PHP has probably got a lot to offer in the server department. Anyway I find this opinion interesting but not really quantifiable.

Collapse
jappyjan profile image
jappyjan

I so fucking agree, even though I stopped using php while ago.

Collapse
loujaybee profile image
Lou — Cloud Engineer

Code Review is a terrible reactive concept that is overly relied on by teams and used as a crutch for bad communication. Pair Programming is significantly more effective at spreading ideas, communication and critiquing code.

Collapse
daniel13rady profile image
Daniel Brady

I agree with your thought on pair programming, but I haven't experienced your view on code reviews. Are you saying that pairing can be a viable substitute for retroactive review?

Unfortunately pairing doesn't happen much in my current environment, and I don't do much to encourage it. In its absence, I think code reviews are better than nothing, but reviewing code effectively is just as challenging as delivering constructive feedback (because that's exactly what it is) and there aren't nearly as many devs who are good at this as there ought to be.

Collapse
loujaybee profile image
Lou — Cloud Engineer

Hey Daniel! :)

I find that often by the time code is up for review it's "too late" to make important changes. As you're wrestling with factors like the sunk cost fallacy and the de-motivating effects of suggesting that a colleague re-do their work seemingly to appease you.

Not only is it often "too late" to make changes but sometimes it's also hard to convey larger feedback via text. Complex changes are often only realistically conveyed in person going through piece by piece. Naturally over time though the amount of "explaining" is asymptotic as you get more and more inline with each others viewpoints.

My take is not that code review is bad (it's important to stress this point) it's just that I see code review is used as a crutch for not having adequate conversations prior and during the creation of code (since it's reactive in nature). And pair programming in my opinion is superior at type of communication.

However I know that my opinion is unpopular since I'd say the majority of developers I've worked with would admit that they dislike pair programming, which seems to tally your experience too so until the day comes that the industry invites more pairing I'll be over here shouting into the void! 😂

Thread Thread
daniel13rady profile image
Daniel Brady

Thanks for elaborating!

Honestly I quite enjoy pairing, but I've recently found myself in a remote work position that is also separated by about 8hrs from my teammates, which makes any sort of synchronous communication difficult. I've been experimenting with opening up a PR as soon as I make a first commit to a branch, and tagging my teammates with the hopes of exchanging feedback "early and often." I've met with mixed success, depending on how available my teammates are.

Thread Thread
nickdrouin profile image
Nick Drouin

For large stories, I try to push my team's / teammates to use a two-phased PR: one for the interfaces/design, a second for the code.
This promotes discussion on the approach early on.

Collapse
aaronktberry profile image
Aaron Berry

I agree. I always found it daunting looking at a PR with 40+ files changed without even knowing what the PR should be doing. In the end, it always seemed to just end up being more efficient sitting down with the owner of the PR and them walking through what changed and reviewing it with them.

Oh and also actually getting the person to RUN the code to see it actually is doing what they expect it to do rather than assuming its working correctly.

Collapse
patryktech profile image
Patryk

I always found it daunting looking at a PR with 40+ files changed without even knowing what the PR should be doing.

Do you even CI, bro? :D

I'd consider looking into Continuous Integration. Smaller commits are oftentimes safer commits.

Collapse
jessekphillips profile image
Jesse Phillips

Plug

Or a little more specific

Code review should include reviewing the history, it is such an important log, those in person conversations need written down for the poor maintenance folks when both of you aren't available.

Collapse
adam_cyclones profile image
Adam Crockett

God yes!

Collapse
mpuckett profile image
Michael Puckett

git rebase > git merge

Collapse
bpedroza profile image
Bryan

90% of native apps should have been a PWA.

Collapse
ar10642 profile image
Andrew Richardson

iOS installation is still so terrible though 😔

Collapse
bpedroza profile image
Bryan

True, background sync might be a deal breaker for some apps too. Hopefully Apple gets it together on this front soon.

Collapse
lukeshiru profile image
▲ LUKE知る

I completely agree!

Collapse
helleworld_ profile image
Desiré 👩‍🎓👩‍🏫

Material Design is not the only valid design system. Open your mind.

Collapse
christopy profile image
Christopher Ribeiro

Material Design sucks!

Collapse
laurenclark profile image
Lauren Clark

Material Design absolutely sucks so much.

Thread Thread
helleworld_ profile image
Desiré 👩‍🎓👩‍🏫

I see finally humanity stands up for something in common

Collapse
micahlt profile image
Micah Lindley

I actually love MD, but it's a pain to work with on the frontend and it's very overused.

Collapse
jessekphillips profile image
Jesse Phillips

I don't know, I feel like I'm just one big unpopular opinion. Where do I start.

  • Vim
  • Dvorak
  • Linux over Windows
  • git history rewrite ftw
  • don't use yaml
  • TDD or testable code can create harder to read code (which could be a detriment
  • there is no full regression
  • dynamic typed languages are harmful to quality

Oh, lighthearted, AI will not take over the world because humanity will have already subsided control before machines could create a plan.

Collapse
daniel13rady profile image
Daniel Brady

Vim

I use Spacemacs in evil mode 😀

Dvorak

I've used "Programmer Dvorak" for the last year and love it, but it has ruined my ability to type on other people's computers 😆😭

Linux over Windows

Most definitely. I use Mac at the moment, but I'd order them as Linux > Mac > Windoze

Collapse
patarapolw profile image
Pacharapol Withayasakpunt

The only problem I saw with YAML is that it is overdone.

  • Who the hell would use no and yes?
  • Strings should always be quoted.
  • safeDump / safeLoad should be default, and probably dump / load should be renamed to fullDump / fullLoad, or dangerous, or just use a custom Encoder / Decoder

I saw no problem with indentation-based languages, though. That is why Markdown is popular.

Collapse
Collapse
greenroommate profile image
Haris Secic

Likes goes to TDD and dynamic typed things. Vim I disagree I think editors should be a matter of taste and never to be discussed xD.

Collapse
jessekphillips profile image
Jesse Phillips

You don't understand, vim stands for VI Improved. You're missing out on some very nice additions, like multiple undo, by sticking with vi.

Closing your eyes to the changes happening will just just hamper your growth. xD

Collapse
tcgumus profile image
Tuna Çağlar Gümüş

IDEA is way better than Eclipse and Netbeans.

Collapse
jappyjan profile image
jappyjan

All jetbrains ide's are just awesome.

Collapse