I'd like to extend my heartfelt fuck-you to the following persons:

- The recruiter who told me that at my age I wouldn't find a job anymore: FUCK YOU, I'll send you my 55 birthday's cake candles, you can put all of them in your ass, with light on.

- The Project Manager that after 5 rounds of interviews and technical tests told me I didn't have enough experience for his project: be fucked in an Agile way by all member of your team, standing up, every morning for 15 minutes, and every 2 weeks by all stakeholders.

- The unemployment officer who advised me to take low level jobs, cut my expenses and salary expectations: you can cut your cock and suck it, so you'll stop telling bullshit to people

- The moron that gave me a monster technical assignment on Big Data, which I delivered, and didn't gave me any feedback: shove all your BIG DATA in your ass and open it to external integrations

- the architect who told me I should open my horizons, because I didn't like React: put a reactive mix in your ass and close it, so your shit will explode in your mouth

- the countless recruiter who used my cv to increase their db, offering fake jobs: print all your db on paper and stuff your ass with that, you'll see how big you will be

To all of them, really really fuck you.

Why are job postings so bad?
Like, really. Why?

Here's four I found today, plus an interview with a trainwreck from last week.
(And these aren't even the worst I've found lately!)

------

Ridiculous job posting #1:
* 5 years React and React Native experience -- the initial release of React Native was in May 2013, apparently. ~5.7 years ago.
* Masters degree in computer science.
* Write clean, maintainable code with tests.
* Be social and outgoing.

So: you must have either worked at Facebook or adopted and committed to both React and React Native basically immediately after release. You must also be in academia (with a masters!), and write clean and maintainable code, which... basically doesn't happen in academia. And on top of (and really: despite) all of this, you must also be a social butterfly! Good luck ~

------

Ridiculous job posting #2:
* "We use Ruby on Rails"
* A few sentences later... "we love functional programming and write only functional code!"

Cue Inigo Montoya.

------

Ridiculous job posting #3:
* 100% remote! Work from anywhere, any time zone!
* and following that: You must have at least 4 work hours overlap with your coworkers per day.
* two company-wide meetups per quarter! In fancy places like Peru and Tibet! ... TWO PER QUARTER!?

Let me paraphrase: "We like the entire team being remote, together."

------

Ridiculous job posting #4:
* Actual title: "Developer (noun): Superhero poised to change the world (apply within)"
* Actual excerpt: "We know that headhunters are already beating down your door. All we want is the opportunity to earn our right to keep you every single day."
* Actual excerpt: "But alas. A dark and evil power is upon us. And this… ...is where you enter the story. You will be the Superman who is called upon to hammer the villains back into the abyss from whence they came."

I already applied to this company some time before (...surprisingly...) and found that the founder/boss is both an ex cowboy dev and... more than a bit of a loon. If that last part isn't obvious already? Sheesh. He should go write bad fantasy metal lyrics instead.

------

Ridiculous interview:
* Service offered for free to customers
* PHP fanboy angrily asking only PHP questions despite the stack (Node+Vue) not even freaking including PHP! To be fair, he didn't know anything but PHP... so why (and how) is he working there?
* Actual admission: No testing suite, CI, or QA in place
* Actual admission: Testing sometimes happens in production due to tight deadlines
* Actual admission: Company serves ads and sells personally-identifiable customer information (with affiliate royalties!) to cover expenses
* Actual admission: Not looking for other monetization strategies; simply trying to scale their current break-even approach.

------

I find more of these every time I look. It's insane.
Why can't people be sane and at least semi-intelligent?

Fuck the memes.

Fuck the framework battles.

Fuck the language battles.

Fuck the titles.

Anybody who has been in this field long enough knows that it doesn't matter if your linus fucking torvalds, there is no human who has lived or ever will live that simultaneously understands, knows, and remembers how to implement, in multiple languages, the following:

- jest mocks for complex React components (partial mocks, full mocks, no mocks at all!)
- token cancellation for asynchronous Tasks in C#
- fullstack CRUD, REST, and websocket communication (throw in gRPC for bonus points)
- database query optimization, seeding, and design
- nginx routing, https redirection
- build automation with full test coverage and environment consideration
- docker container versioning, restoration, and cleanup
- internationalization on both the front AND backends
- secret storage, security audits
- package management, maintenence, and deprecation reviews
- integrating with dozens of APIs
- fucking how to center a div

and that's a _comically_ incomplete list; barely scratches the surface of the full range of what a dev can encounter in a given day of writing software

have many of us probably done one or even all of these at different times? surely.

but does that mean we are supposed to draw that up at a moment's notice some cookie-cutter solution like a fucking robot and spit out an answer on a fax sheet?

recruiters, if you read this site (perhaps only the good ones do anyway so its wasted oxygen), just know that whoever you hire its literally the luck of the draw of how well they perform during the interview. sure, perhaps some perform better, but you can never know how good someone is until they literally start working at your org, so... have fun with that.

Oh and I almost forgot, again for you recruiters, on top of that list which you probably won't ever understand for the entirety of your lives, you can also add writing documentation, backup scripts, and orchestrating / administrating fucking JIRA or actually any somewhat technical dashboard like a CMS or website, because once again, the devs are the only truly competent ones - and i don't even mean in a technical sense, i mean in a HUMAN sense of GETTING SHIT DONE IN GENERAL.

There's literally 2 types of people in the world: those who sit around drawing flow charts and talking on the phone all day, and those WHO LITERALLY FUCKING BUILD THE WORLD

why don't i just run the whole fucking company at this point? you guys are "celebrating" that you made literally $5 dollars from a single customer and i'm just sitting here coding 12 hours a day like all is fine and well

i'm so ANGRY its always the same no matter where i go, non-technical people have just no clue, even when you implore them how long things take, they just nod and smile and say "we'll do it the MVP way". sure, fine, you can do that like 2 or 3 times, but not for 6 fucking months until you have a stack of "MVPs" that come toppling down like the garbage they are.

How do expect to keep the "momentum" of your customers and sales (I hope you can hear the hatred of each of these market words as I type them) if the entire system is glued together with ducktape because YOU wanted to expedite the feature by doing it the EASY way instead of the RIGHT way. god, just forget it, nobody is going to listen anyway, its like the 5th time a row in my life

we NEED tests!
we NEED to know our code coverage!
we NEED to design our system to handle large amounts of traffic!
we NEED detailed logging!
we NEED to start building an exception database!

BILBO BAGGINS! I'm not trying to hurt you! I'm trying to help you!

Don't really know what this rant was, I'm just raging and all over the place at the universe. I'm going to bed.

Senior development manager in my org posted a rant in slack about how all our issues with app development are from

“Constantly moving goalposts from version to version of Xcode”

It took me a few minutes to calm myself down and not reply. So I’ll vent here to myself as a form of therapy instead.

Reality Check:
- You frequently discuss the fact that you don’t like following any of apples standards or app development guidelines. Bit rich to say the goalposts are moving when you have your back to them.

- We have a custom everything (navigation stack handler, table view like control etc). There’s nothing in these that can’t be done with the native ones. All that wasted dev time is on you guys.

- Last week a guy held a session about all the memory leaks he found in these custom libraries/controls. Again, your teams don’t know the basic fundamentals of the language or programming in general really. Not sure how that’s apples fault.

- Your “great emphasis on unit testing” has gotten us 21% coverage on iOS and an Android team recently said to us “yeah looks like the tests won’t compile. Well we haven’t touched them in like a year. Just ignore them”. Stability of the app is definitely on you and the team.

- Having half the app in react-native and half in native (split between objective-c and swift) is making nobodies life easier.

- The company forces us to use a custom built CI/CD solution that regularly runs out of memory, reports false negatives and has no specific mobile features built in. Did apple force this on us too?

- Shut the fuck up

I'm editing the sidebar on one of our websites, and shuffling some entries. It involves moving some entries in/out of a dropdown and contextual sidebars, in/out of submenus, etc. It sounds a little tedious but overall pretty trivial, right?

This is day three.
I learned React+Redux from scratch (and rebuilt the latter for fun) in twice that long.

In my defense, I've been working on other tasks (see: Alerts), but mostly because I'd rather gouge my freaking eyes out than continue on this one.

Everything that could be wrong about this is. Everything that could be over-engineered is. Everything that could be written worse... can't, actually; it's awful.

Major grievances:
1) The sidebars (yes, there are several) are spread across a ridiculous number of folders. I stopped counting at 20.
2) Instead of icon fonts, this uses multiple images for entry states.
3) The image filenames don't match the menu entry names. at all. ("sb_gifts.png" -> orders); active filenames are e.g. "sb_giftsactive.png"
4) The actions don't match the menu entry names.
5) Menu state is handled within the root application controller, and doesn't use bools, but strings. (and these state flags never seem to get reset anywhere...)
6) These strings are used to construct the image filenames within the sidebar views/partials.
7) Sometimes access restrictions (employee, manager, etc.) are around the individual menu entries, sometimes they're around a partial include, meaning it's extremely difficult to determine which menu entries/sections/subsections are permission-locked without digging through everything.
8) Within different conditionals there are duplicate blocks markup, with duplicate includes, that end up render different partials/markup due to different state.
9) There are parent tags outside of includes, such as `<ul>#{render 'horrific-eye-stabbing'}</ul>`
10) The markup differs per location: sometimes it's a huge blob of non-semantic filthiness, sometimes it's a simple div+span. Example filth: section->p->a->(img,span) ... per menu entry.
11) In some places, the markup is broken, e.g. `<li><u>...</li></u>`
12) In other places, markup is used for layout adjustments, such as an single &nbsp; nested within several divs adorned with lots of styles/classes.
13) Per-device layouts are handled, not within separate views, but by conditionally enabling/disabling swaths of markup, e.g. (if is_cordova_session?).
14) `is_cordova_session` in particular is stored within a cookie that does not expire, and within your user session. disabling it is annoying and very non-obvious. It can get set whether or not you're using cordova.
15) There are virtually no stylesheets; almost everything is inline (but of course not actually everything), which makes for fun layout debugging.
16) Some of the markup (with inline styling, no less) is generated within a goddamn controller.
17) The markup does use css classes, but it's predominately not for actual styling: they're used to pick out elements within unit tests. An example class name: "hide-for-medium-down"; and no, I can't figure out what it means, even when looking at the tests that use it. There are no styles attached to that particular class.
18) The tests have not been updated for three years, and that last update was an rspec version bump.
19) Mixed tabs and spaces, with mixed indentation level (given spaces, it's sometimes 2, 4, 4, 5, or 6, and sometimes one of those levels consistently, plus an extra space thereafter.)
20) Intentional assignment within conditionals (`if var=possibly_nil_return_value()`)
21) hardcoded (and occasionally incorrect) values/urls.

... and last but not least:
22) Adding a new "menu sections unit" (I still haven't determined what the crap that means) requires changing two constants and writing a goddamn database migration.

I'm not even including minor annoyances like non-enclosed ternaries, poor naming conventions, commented out code, highly inefficient code, a 512-character regex (at least it's even, right?), etc.

just.

what the _fuck_

Who knew a sidebar could be so utterly convoluted?

I now know why people don't write tests.

Been trying to get started with React unit tests for weeks now.

Hope Driven Development FTW.

the year is 2050
- Linux is written in Rust and called Windows
- Python 2 market share increased by 2% since 2023
- The latest JS framework to finally solve everything just came out, and this time it’s the real deal. The exact same thing also happened in 2045, 2041, 2037, 2035, 2030 and 2026
- More than 60% of every CPU is hardware JS cores
- React became a separate language
- Sentient Copilot refused to write code in it
- Unit tests are illegal in three states
- Google had changed their motto from “Do The Right Thing” to “Do At Least Something”
- Chrome OS was rewritten in JS
- CSS is Turing-complete

Why do people have to lie? I am seriously getting tired of it.

Context: While I was on vacation the company hired some guy we’ll call Bob.
Bob is a senior with 10+ years of experience. 5 of those years in React (supposedly).
I got back from vacation and was told I’d be working on a project with Bob.
I’ve worked in teams before so I thought no problem.

Now I am aware that different people have different styles, so that’s why we agreed on a lint config with some fancy git hooks.

I was excited at first because the project actually seems nice, but my excitement soon turned into terror.

First of all, Bob doesn’t seem to understand Git…fair enough, I’ll give him a quick guide…

Mf calls me at 11pm on a Friday because he can’t push because the tests are failling.

Now tests. Bob doesn’t write those. Great.

We had created a few components to use throughout the project.

Bob seems to consistently forget what components are and why you write them and just imports the defaults from the UI library we’re using.

Bob also has a kink for hardcoding values for some reason.

I talked to Bob multiple times about this and he just tells me he’ll change it but in the end the PR stays open for 5 days, before it’s actually me who goes in and fixes it. Oh and yeah this shit keeps happening over and over again.

Now I know some of us devs hate meetings but for the love of God Bob just show up. You don’t even have to speak. Or at least answer a message that corresponds to the working hours and not in the middle of the night.

I am getting tired of this behavior and am seriously holding back from reporting this to the management. It’s been a month and I am seriously worried about the project. I have my own stuff to do but it takes time for me to clean up his absolute mess that doesn’t even pass the CI.

Call me an asshole I don’t care. It’s been a month and I’m legit worried about the future of the project.

I fucking HATE testing JavaScript. It's such fucking bullshit. I've been struggling to test one simple functionality for multiple hours. It's probably one stupid thing I can't figure out, so I hope some sleep will grant me a fresh look tomorrow.

Also it's absolute bullshit the amount of libraries and dependencies you need to have to get some proper scalable tests going. Jasmine, Babel, ES2015, yarn/npm (because Jenkins is too fucking old to handle yarn). React, react test helpers, webpack. The list continues. FUCK OFF!

New country, new company, new team, new projects.
I'm supposed to be the TL of a team working on a React project.

A guy in his late 40s celebrates himself as "the senior", he basically just finished watching a youtube thing, React 101 crash course or similar. The other two juniors who did only Wordpress so far venerate him like a god.

The code, of course, is one on the finest pieces of crap I ever had the pleasure to deal with in my life: naturally a bunch of JQuery plugins for everything, no tests, no state management, side effects everywhere, shared state and globals like hell, everything written in ES3/ES5 style, no types, no docs, build and deploy totally manual, deep props drilling at every level... and not to mention the console.log() shipped in prod.

First day, already headache.
Full rewrite start tomorrow.
Hiring real devs as well.

Me and my team has been creating React components for the last two months. Today we realized that not a single component is done the Redux way (as pure functions), which means we have to refactor every component and the tests.

That's what you get for trying out new technology..

Realized there was a bug in my npm package that made it hard to update the state of the input field conditionally (rather than explicitly through user action) and fixed it, wrote tests to ensure it was working the way I thought it was, updated the dist, updated the package version, merged, cut a GitHub release...

Then uninstalled and reinstalled it in the project I’m using it in and it didn’t work. What the eff, I think. Take a couple hours furiously trying to figure out why the hell the behavior doesn’t seem to match the behavior of the new version.

Then it dawns on me. I check the package.json.

“react-autosuggestions”: “^2.1.0”

.... I forgot to do the “npm publish” step.

*head desk*

There you are, fiddling with next.js webpack settings, because your isomorphic JS-in-CSS-in-JS SSR fallback from react-native-web to react-dom throws a runtime error on your SSR prerendering server during isomorphic asynchronous data prefetching from Kubernetes backend-for-frontend edge-server with GraphQL.

You have all that tech to display a landing page with an email form, just to send spam emails with ten tracking links and five tracking beacons per email.

Your product can be replaced by an Excel document made in two days.

It was developed in two years by a team of ten developers crunching every day under twelve project managers that can be replaced with a parrot trained to say “Any updates?”

Your evaluation is $5M+. You have 10,000 dependency security warnings, 1000 likes on Product Hunt, 500 comments on Hacker News, and a popular Twitter account.

Your future looks bright. You finish your coffee, crack your knuckles and carry on writing unit tests.

(As a freelancer I was asked to do a couple of tasks on legacy code)

Let’s check this code, how bad can it be?

- all of the following: unreadable mess, no auto linting

- tests: some are there cause there’s not enough automation, others are poorly named
- frontend: somehow a genius made a react component for every variable in the store which only passes the variable to the child (wtf)
- backend: death by best practices
- ci/cd: “we have it but it’s broken”

Let’s fucking goooo 😎

Diagnosis: my therapist is getting rich
Chances to not cry tonight: close to zero

At least they pay well 🤷‍♂️

You built awesome web application with React and Node. Your forgot to write tests.

Your production is failing, Harry

The moment you realize that you have successfully beaten reality with your unit-tests...

There are unit-tests for ...
... the api returning a 408 Http StatusCode when an internal request times out.
... the react app take this status-code and fires an action to display a specific error message for the user.

Every bit of code runs just fine.

Deploy this hell of an app on the server. Dandy Doodle.

Do a smoketest of the new feature.
FAIL!
Chrome starts to crumble during runtime. The api Request freezes.
Firefox takes the 408 api response but fails to interpret it in react app.

So I began to wonder, what the hell is going on.

Actually I recognized that I had the glorious idea to return a clientside error code in a serverside api response.
Glorious stupidity :/

Finally I fixed the whole thingy by returning an 504 (Gateway timeout) instead of 408 (Clientside timeout)

Cheers!

I recently started learning Erlang. This is the story of how I got trapped into it.

When I code, I usually use my trusty text editor and a terminal to either compile my code or run tests in the language interpreter. The interpreter, erl, works fine, but when I wanted to close it, I ran into a small issue.
Because I never know what the command is to close an interpreter, I usually use the EOF character (^D), that is widely recognized. Except erl does not react to it, not even a tiny message saying it won't close or doesn't recognize the output.
Alright then, let's try quit. That's an atom, it does not behave how I want.
quit() is an undefined shell command, exit() terminates the shell process but the interpreter automatically starts a new one...
But I get the welcome message, telling me to abort with ^G! Some progress, finally... except ^G redirects from Erlang interpreter to user switch command. Damn, another interpreter...

I ended up killing the process from an other terminal.

Long story ahead

Background:
I recently started a job in a smallish startup doing web development in a mostly js stack as an entry-junior engineer/dev. I’m the only person actively working on our internal tools as my Lead Engineer (the only other in house dev) is working on other stuff.

Now I was given a two week sprint to rebuild a portion of our legacy internal app from angular 1.2 with material-ui looking components with no psd’s or cut-outs of any kind to a React and bootstrap ui for the front end and convert our .net API routes into Node.js ones. I had to build the API routes, SQL queries (as there were plenty of changes and reiterations that I had to go through to get the exact data I needed to display), and front end. I worked from 9am until 11pm every day for those two weeks including weekends as our company has a huge show this upcoming week.

I finish up this past sunday and push to our staging environment. The UI is 5.5/10 as we’re changing all of our styling to bootstrap and I’m no ui expert. The api has tests and works flawlessly (tm).

So we go into code review and everything is working as expected until one tab that I made erred out and was written down as a “Needs to be fixed.”

This fix was just a null value handler that took three minutes and a push back to staging, but that wasnt before a stupendous amount of shit being flung my way for the ui not looking great and that one bug was a huge deal and that he couldnt believe it slipped through my fingers.

Honestly, I’m feeling really unmotivated to do anything else. I overworked myself for that only to be shit on for one mistake and my ui being lack-luster with no guides.

Am I being a baby about this or is this something to learn from?

Started porting one application written in php to:
Golang(and some libraries to make certain sht simpler like GORM and Gorilla amongst a couple of others, most shit is STD shit already built in)

Java Spring(I know it well, but wanted to try this particular app in it, lots of boilerplate although the coded is solid AF)

.NET Core API, which I separated in a series of modules for the domain interface, the persistence logic, the actual api etc, I really dig it. It has a basic React frontend in Typescript whereas the other 2 versions are using the standard Go html/template package and the Twig interface for Spring.

My favorite thus far is Golang. I find it extremely easy to extend, the language reads good enough for a retard like myself to make sense of it fairly easy, really easy to test and experiment with it, any idea I get for something to add(say users and stuff) took me less than 30 mins to figure out while reading the actual documentation, as in the base documentation or just the source code.

I know the language is retard proof, and I am highly enjoying this. Not to say that the other two are bad, not at all, been using C# and Java for years now, but I highly appreciate being able to concentrate on functionality rather than all the fucking architectural boilerplate needed to run basic shit in the other two frameworks. Thus far Golang has been a breath of fresh air the likes Clojure gives me, while not even being a profound or mind blowing language in terms of features(since other than the interface{} and goroutines i can't think of shit) and have not reached a scenario in which I am stuck or dying to have generics one bit for the overall business logic.

The app is growing like crazy in terms of code since the original php application was huge to begin with, but dear me this shit is as simple as it can get without being too technical. Might move it to production once all usability tests pass and force the rest of the staff to learn it. I have one lead dev that damn near refuses to touch anything other than php, and a very eager to try shit out content administrator that comes from a Java and C# background.

all I want to say is how much I love go haha

To me this is one of the most interesting topics. I always dream about creating the perfect programming class (not aimed at absolute beginners though, in the end there should be some usable software artifact), because I had to teach myself at least half of the skills I need everyday.

The goal of the class, which has at least to be a semester long, is to be able to create industry-ready software projects with a distributed architecture (i.e. client-server).

The important thing is to have a central theme over the whole class. Which means you should go through the software lifecycle at least once.

Let's say the class consists of 10 Units à ~3 hours (with breaks ofc) and takes place once a week, because that is the absolute minimum time to enable the students to do their homework.

1. Project setup, explanation of the whole toolchain. Init repositories, create SSH keys for github/bitbucket, git crash course (provide a cheat sheet).
Create a hello world web app with $framework. Run the web server, let the students poke around with it. Let them push their projects to their repositories.
The remainder of the lesson is for Q&A, technical problems and so on.

Homework: Read the docs of $framework. Do some commits, just alter the HTML & CSS a bit, give them your personal touch.
For the homework, provide a $chat channel/forum/mailing list or whatever for questions where not only the the teacher should help, but also the students help each other.

2. Setup of CI/Build automation. This is one of the hardest parts for the teacher/uni because the university must provide the necessary hardware for it, which costs money. But the students faces when they see that a push to master automatically triggers a build and deploys it to the right place where they can reach it from the web is priceless.
This is one recurring point over the whole course, as there will be more software artifacts beside the web app, which need to be added to the build process. I do not want to go deeper here, whether you use Jenkins, or Travis or whatev and Ansible or Puppet or whatev for automation. You probably have some docker container set up for this, because this is a very tedious task for initial setup, probably way out of proportion. But in the end there needs to be a running web service for every student which they can reach over a personal URL. Depending on the students interest on the topic it may be also better to setup this already before the first class starts and only introduce them to all the concepts in a theory block and do some more coding in the second half.

Homework: Use $framework to extend your web app. Make it a bit more user interactive with buttons, forms or the like. As we still have no backend here, you can output to alert or something.

3. Create a minimal backend with $backendFramework. Only to have something which speaks with the frontend so you can create API calls going back and forth. Also create a DB, relational or not. Discuss DB schema/model and answer student questions.

Homework: Create a form which gets transformed into JSON and sent to the backend, backend stores the user information in the DB and should also provide a query to view the entry.

4. Introduce mobile apps. As it would probably too much to introduce them both to iOS and Android, something like React Native (or whatever the most popular platform-agnostic framework is then) may come in handy. Do the same as with the minimal web app and add the build artifacts to CI. Also talk about getting software to the app/play store (a common question) and signing apps.

Homework: Use the view API call from the backend to show the data on the mobile. Play around with the mobile project to display it in a nice way.

5. Introduction to refactoring (yes, really), if we are really talking about JS here, mention things like typescript, flow, elm, reason and everything with types which compiles to JS. Types make it so much easier to refactor growing codebases and imho everybody should use it.
Flowtype would make it probably easier to get gradually introduced in the already existing codebase (and it plays nice with react native) but I want to be abstract here, so that is just a suggestion (and 100% typed languages such as ELM or Reason have so much nicer errors).
Also discuss other helpful tools like linters, formatters.

Homework: Introduce types to all your API calls and some important functions.

6. Introduction to (unit) tests. Similar as above.
Homework: Write a unit test for your form.

(TBC)

I'm in a team of 3 in a small to medium sized company (over 50 engineers). We all work as full stack engineers.. but I think the definition of full stack here is getting super bloated. Let me give u an example. My team hold a few production apps, and we just launched a new one. The whole team (the 3 of us) are fully responsible on it from planning, design, database model, api, frontend (a react page spa), an extra client. Ok, so all this seems normal to a full stack dev.

Now, we also handle provisioning infra in aws using terraform, doing deployments, building a CI/CD pipeline using jenkins, monitoring, writing tests, building an analytics dashboard.

Recently our tech writer also left, so now we are also handling writing feature releases.

Few days ago, we also had a meeting where they sort of discussed that the maintenance of the engineering shared services, e.g. jenkins servers, (and about 2-3 other services) will now be split between teams in a shared board, previously this was handled only be team leads, but now they want to delegate it down.

And ofcourse not to mention supporting the app itself and updating bug tickets with findings.

I feel like my daily responsiblities are becoming the job responsibilities of at least 3 jobs.

Is this what full stack engineering looks like in your company? Do u handle everything from app design, building, cloud, ops, analytics etc..

My personal laptop suddenly broke.

Clearly, something in the motherboard got broken, because no LED is working, long press for hard reset is not working: only fans are on when I power on the button. To disconnect I should remove the battery.

It's an old (and very loved by me) laptop, but I explained it in the repair shop, and they told me they "will do all possible to repair it" by a reasonable price, so worth it.

After some days the call me to tell me that, after some tests like a display test or ram test, the problem is probably in the motherboard and they don't have the tools to fix that.
They can bring the laptop to another specialized shop for, of course, a much more expensive price.

How should I react? I'm very angry. When you told me you could "do all possible to repair it" after I told you where the problem probably is, it implies you have the tools, at least, to find out if the problem were there.

When we talk I said "yes, I accept I'll pay that price if you aren't able to fix it".
Being coherent, are you expecting to me to have the tools to pay you in that case?

I'm so tired of the impunity of companies for treating customers as if they had no idea about technology always even if in the most of cases is it. (My laptop was not apple)

What a waste of time and money.

Since the end of my extended internship is slowly coming forth, I thought I'd (happily) ramble in the Random section for a bit:
*TL,DR: Internship went well, I learnt a lot*

The company I worked at made my experience with Frontend make huge leaps. I used both Vue and React, neither of which I had used before. I also learnt that you could mock things in unit tests instead of simulating full use. Finally, I also improved my experience with Kotlin again.
Both teams I have been in (since there was a switch due to a lot of people taking off days for holidays) told me that I am quite fast at grasping concepts I hadn't even heard of before, which is quite nice :)

Anyway, I wonder what the transition to school is going to be like.

How to fail my interview 101:
1. Change your GitHub status to "I love learning new things every day"
2. Start by showing off your code katas
3. "React is the best way to do frontend"
4. "Unit tests are necessary"
5. "TypeScript is better than JavaScript"
6. "I don't have to learn CSS, I use Tailwind"

Hm... Apparently I've been doing TDD all along... it's just that I don't save the tests in a seperate project.

I just keep editing Main() to test whatever i'm working on (each class).

Also the NJTransit site is sneaky as ****. It seems the devs know a bit about how to prevent site scraping by checking Headers and Client information...

Took all afternoon to get this test to pass....

it works in Chrome but not in my code... and even after I spoofed all the headers... including GZIP.... it wouldn't work for multiple requests...

I need to create a new WebClient for each request.... no idea how it knows the difference or why it cares... maybe it's a WebClient bug...

And this is only the test app. Originally was supposed to be built in React Native but that has it's own problems...

Books are too old, the examples don't work with the latest...

But I guess this also has a upside... learn TDD and React rather than just React... hopefully can finish this week...

I'm actually on vacation... yea... i still code like a work day... 10AM - 8PM....

React Native testing is hair pulling.

Every test needs to have 100 different mocks in place and there are: 3 different methods to mock a function (mock, mockImplementation, and fn), 3 different types of query methods to get elements (get, find, and query), and 5 different selectors to query on (accessibility label, testId, accessibility hint, accessibility value, etc.)

And after reading all this, being diligent and learning the difference between stupid, synonymously-named functions which have wildly different side effects like "getByA11yHint" and "findByA11yHint" (ugh...), after all that, you write out a test with all the appropriate mocks and you want to do something simple and it beats you up all over again.

Button enabled or button disabled. Simple right? Logically the former is "expect(elem).toBeEnabled()" and the latter is "expect(elem).not.toBeEnabled()", right?

Wrong! You're an imbecile. Your tests will fail and never tell you that ".not.toBeEnabled()" and ".toBeDisabled()" don't do the same thing even though they look and sound exactly the same. Only the latter will work. The former makes all your tests fail. Where is this written in the docs? Nowhere?! Great!

👌😄🔫

Slacking off on tests for medium size projects. I have one project that I consider a major achievement as of today, the NPM package @lbfalvy/react-await. It has like two tests and it does a _lot_ more than two things.

Don't get me wrong, I test it thoroughly, but not in an automated way.

It's the 5th day of my holiday, circa 10.20 AM. So far I've spent around 30h programming, and learned React (already having experience with the other 2 major ME*N stacks I decided it was time to give it a go), made a small 2D platformer with Unity and realised I really like writing unit tests. Maybe next I refactor the app I just made to use GraphQL and TypeScript next, since I'm in the mood of trying something new.

Funny how my significant other thought being on holiday actually would mean a break from programming - no, it means more time to spend learning and trying things you don't have the time or energy to after a working day of Vue/C#!

(To clarify, I would not spend this much time programming on my holiday, if my better half wasn't away from home for this week - won't probably spend nearly as much time on it for the remaining 4 weeks...)

I’m so sorry if this is the place for questions. I’m terrified of stack overflow and have been searching for a week for a solution and can’t find one. This is for React.js people.

I was tasked to create a webpage with react. The limitation is, they did not wanna adopt the node.js dependency. I said ok, I’ll figure it out. You can inject react, material UI, and babel with script tags in HTML, then put ur lil components in it. I did that and it works beautifully.

However, now I have to write tests for this. I think it’s actually impossible without a way to render React, so I have to use the browser, or node, right? I convinced my boss to allow me to use a node.js container just for testing, which I thought would make my life easier.

I don’t know how to render this thing with node. It’s just an HTML file that pulls react via script tags, and idk how to serve html with node. Additionally, none of the React testing libraries seem to support testing a system that wasn’t designed to be served with node, at least not easily. My gut tells me that the complication with how things are imported contributes at least a little to this (dependencies pulled via script tags in the HTML file and made available to react through global const variables).

I could be wrong about any of this — im fairly new. But how tf do I go about testing these react components? For reference, if you go to Reacts docs, there’s a section called “add react to a page in one minute” that’s pretty much what I did.

Realized what the meaning of life was yesterday.

Because the real meaning of life is yet to be found, there is an interim one — to do everything to help us exist as longer as possible as a species. So spread peace, empathy and forgiveness. If we live long enough to formulate the theory of everything, understand human brain and evolve past/patch our brains to avoid being greedy violent fucks, maybe then we'll find the real meaning. The longer we exist for, the better our chances are.

So, the ideal human according to kiki is:
- one that doubts everything and is free because of that. Freedom is doubt.
- one that has a habit of denying themselves pleasures. Without restraining themselves, one turns into a greedy, violent beast.
- actively contributes to the world peace & spreads peace among their peers, as true impact is immeasurable, and who knows, maybe butterfly effect will turn one “I'm sorry, I was wrong” into avoiding nuclear catastrophe.

There are adversaries that benefit from us bickering and fighting each other. They want to divide us. Let's deny them that. I announce that I won't engage in verbal battles and teardowns anymore.

Sometimes, static typing is beneficial. Sometimes, unit tests are necessary. JS, CSS and web platform as a whole are not perfect. JS is not perfect. Apple does anti-consumer stuff. Not all rich people deserve hate. Sass has its uses. Tailwind CSS has its uses. React has its uses.

Peace

You're kidding. You know how React, GraphQl, and Jest are made by facebook. You would think that Jest then would be framework of choice for mocking gql queries and responses for a React app. And you would be wrong. You "can, but-", depending on your implementation - ours being based on official sources - not without contorting and duplicating everything related to the query implementation at which you are barely even testing the app itself. We're using named imports from .gql files, for those familiar.

Don't you hate it when it turns out the guy going "nah tests were too hard, we didn't bother" was right.

Shallow() or To Mount()....shit react tests have been killing me. The issues on github have not been resolved. And our team lead has insisted on them even more. Haha they way I have been ditching them.

Recently I completed a whole year in programming. Holy jebus, I have no idea I could make it through.
I started thinking I was "decent" at this because I had taken a half dozen courses in python plus some algorithm logic in school lol @ innocent me
I'm an applied math student and I hereby declare I was the most incompetent dude you'll ever see.
I've been through so much shit I didn't realize I had a shitty boss, because one would think it's normal for a beginner to approach everything in programming because I was told to do so. Full blown restful apis, stateful redux react apps with responsive CSS using Google's material design. Don't forget to dockerize everything and deploy the swarm on Amazon cloud all the while having to run integration unit tests, make sure all the rules on your nginx are correct we don't want exposure do you know how to write a visualization tool on JavaScript so we can 3d-fy some x-ray prints and good luck balancing tight schedules with your school and girlfriend ye right lul
My manager would ask me to deliver new shit to an app I was developing mostly by my self in react (I barely even knew what RFC or ES6 was by the time I started).
I got fired from this project because I couldn't deliver by myself what 5 experienced dudes could (debatable, but still... Cuz they couldn't when they took over. Boss wanted to rewrite the whole app in a week and a half)
Turns out I got called back by the same company but to contribute in another project. This time to automate some shizzle with python.
Feelsgoodman but I want out ASAP can't stay sane for longer

So I'm here after a long break coz my life is shit all over again, and only devRant allows me to rant officially.

I was selected by a recruiter visiting our college in very early days of the campus placements, September last year,

Problem 1:
I wasn't allowed to sit in any of the other recruitment drives by the college, even when I didn't really like the job profile I was in

Problem 2:
The company is taking 12 tests and wants me to work on 3 Projects of bootstrap, rails, and react each, before they give me joining.

Here I am working like an asshole with all frustrations after my college got over to finish the tasks without a penny.

This frustration is only causing more and more delay in my work.

I've been since friday with my boss trying to implement bridge between an SDK of another company for Android and iOS (yes the project is in React Native).
Today I've managed to put all the code that is needed to make that bridge and made tests. But in order to test the SDK functions, we need the info that should be easy to request through a service... The service is made with soap, using a certificate .p12.

*No problem, follow the documentation and everything will be okay* I thought... Even the example request in the docs doesn't give a 200 response. And when we finally made a 200 request, it still returned and error code...

And this isn't even the best part. Today we talked to the person that has been collaborating with us, and even he says "Implementing with this company is always hard". Even their worker knows it!!!!

Finding out React components score very low on accessibility tests.

This applies especially to imported libraries.

If anyone has any good tips after a similar experience, do share.

I just commented a test so the PR passes and the feature reaches next release; I can't fix it (Damn react testing library tests)

but after that, the linter failed for the same PR, so I just fixed it and did a git push -f

I guess once you cross the line you cannot come back

feel my pain

What's the worst part about testing React components? Using the equivalent of fucking stone tools to do your component integration tests! We got errors with no context and errors with no stack trace, just spewing out bullshit! A sample:

The classic "Can't access .root on unmounted test renderer"

The unforgettable and ALWAYS visible "Warning: An update to YourShittyComponent inside a test was not wrapped in act(...)."

We do love it!

If you upgrade your framework/php/React version then you need to have tests to makes sure nothing breakes after upgrade!?

Ive never seen a project with tests that completly covers everything and ive been a developer (web) for over 10 years.

Without tests you just upgrade, get down on your knees and pray?

tests boy
- balding in his late twenties
- thinks that React is a framework
- favorite book is either 1984 or fight club
- came to IT to make an impact but obviously lacks determination to do so. Prefers not to think about it
- doesn’t know why and for what he wakes up every morning. Stopped thinking about it 7 years ago
- has a girlfriend that doesn’t allow him to penetrate her, only hugs and cunnilingus
- already forgot how does a blowjob feel like
- when it’s too hot in his room when he tries to sleep, he gets up and opens the window, and after that he doesn’t want to sleep anymore, and tomorrow is a yet another working day
- unexpected slack message sound he hears when not at the office triggers his fight or flight response
- still salty about CSS vertical-align: middle not instantly centering the element vertically
- just like 5 years ago, every day he thinks that after he learns That New Thing, he’ll begin The Real Life, and his current career state is temporary
- loves to say “it’s not my job” but only says that if absolutely sure that he won’t be reported for that
- uses vscode
- thinks he’s an engineer

Unit tests are usefule or uneeded in develepment (Node.js, React,Angular,etc...)