So I spent 4-5 weeks explaining how shit the current code base was, implemented gulp tasks to lint js, CSS etc, written shed loads of coding standards and best practices to follow. At this point everyone was onboard with the changes and thought brilliant were going to start getting some good code coming out of this team.

I go on holiday for a week, come back and fucker has ignored the documentation disabled the linters in the gulp tasks and the code is back to square one SHIT!!

Plus everyone still committing to master!!!!

Why do I bother!!

writing library code is hard.

there are sooo many details that go into writing good libraries:

designing intuitive and powerful apis
deciding good api option defaults, disallowing or warning for illegal operations

knowing when to throw, knowing when to warn/log
handling edge cases
having good code coverage with tests that doesn't suck shit, while ensuring thry don't take a hundred years to run

making the code easy to read, to maintain, robust
and also not vulnerable, which is probably the most overlooked quality.

"too many classes, too little classes"

the functions do too much it's hard to follow them
or the functions are so well abstracted, that every function has 1 line of code, resulting in code that is even harder to understand or debug (have fun drowning in those immense stack traces)

don't forget to be disciplined about the documentation.

most of these things are
deeply affected by the ecosystem, the tools of the language you're writing this in:

like 5 years ago I hated coding in nodejs, because I didn't know about linters, and now we have tools like eslint or babel, so it's more passable now

but now dealing with webpack/babel configs and plugins can literally obliterate your asshole.

some languages don't even have a stable line by line debugger (hard pass for me)

then there's also the several phases of the project:

you first conceive the idea, the api, and try to implement it, write some md's of usage examples.

as you do that, you iterate on the api, you notice that it could better, so you redesign it. once, twice, thrice.

so at that point you're spending days, weeks on this side project, and your boss is like "what the fuck are you doing right now?"

then, you reach fuckinnnnng 0.1.0, with a "frozen" api, put it on github with a shitton of badges like the badge whore you are.

then you drop it on forums, and slack communities and irc, and what do you get?

half of the community wants to ban you for doing self promotion

the other half thinks either
a) your library api is shitty
b) has no real need for it
c) "why reinvent the wheel bruh"

that's one scenario,

the other scenario is the project starts to get traction.

people start to star it and shit.
but now you have one peoblem you didn't have before: humans.

all sorts of shit:

people treating you like shit as if they were premium users.

people posting majestically written issues with titles like "people help, me no work, here" with bodies like "HAAAAAAAAAALP".

and if you have the blessing to work in the current js ecosystem, issues like "this doesn't work with esm, unpkg, cdnjs, babel, webpack, parcel, buble, A BROWSER".
with some occasional lunatic complaining about IE 4 having a very weird, obscure bug.

not the best prospect either.

Structure: decades of programming in too many languages to enumerate. I lean functional, but only when the language doesn't fight it. No matter what I'm doing, my code is immutable in practice, if not paradigm.

Syntax: No one thing in particular. I code differently depending on the language.

When I start learning a language, I'll find the standard style checker and create a project where I write an example of every single rule.

The end result is generally a quick intro to the language and a bonus understanding of the hot sports opinion in said language. I call this an ocean boiler.

I lean heavily into autoformatting because I've worked on too many projects to care, and I have a general expectation that something which is important enough to make a code standard is important enough to be enforced in tooling. I'd rather spend my time solving problems that thinking about stylistics.

Programmers nowadays have to...
… write 100%-covering unit tests;
… set up continuous integration, linters, hinters, style checkers, …;
… follow style guides for every language;
… meet impossible deadlines;
… meet impossible management/customer/end user expectations;
… read through terrible code others made;
… read through terrible documentation others made;
… make terrible documentation themselves;
… fight with the IDE;
… fight with the build tools;
… deal with unreproducible crash reports coming in from everywhere;
… debug code written at 2am (by themselves AND others);
…
…
…
… KNOW HOW TO PROGRAM.

Too many to count, but this one useless meeting stands out the most.

I was working as an outside dev for software corporation. I was hired as an UI dev although my skill set was UI/engineer/devops at the time.

we wrote a big chunk of 'documentation' (read word files explaining features) before the project even started, I had 2 sprints of just meetings. Everybody does nothing, while I set up the project, tuned configs, added testing libraries, linters, environments, instances, CI/CD etc.

When we started actual project we had at least 2 meetings that were 2-3 hours long on a daily basis, then I said : look guys, you are paying me just to sit here and listen to you, I would rather be working as we are behind the schedule and long meetings don't help us at all.

ok, but there is that one more meeting i have to be on.

So some senior architect(just a senior backend engineer as I found out later) who is really some kind of manager and didn't wrote code for like 10 years starts to roast devs from the team about documentation and architectural decisions. I was like second one that he attacked.

I explained why I think his opinion doesn't matter to me as he is explaining server side related issues and I'm on the client-side and if he wants to argue we can argue on actual client-side decisions I made.

He tried to discuss thinking that he is far superior to some noob UI developer (Which I wasn't, but he didn't know that).

I started asking some questions and soon he felt lost and offended. We ended that discussion with conclusion that I made my own decisions on the client-side. That lasted less than 10 minutes.

So I just sit there and eat popcorn for next 4 and half hours listening to their unnecessary discussions where some angry manager that did programing decades ago wanted to show that we are all noobs and stupid.

what a sad human being.
what a waste of time, but hey I got payed for this 5 hour meeting.

I love linters and all. They’re great for maintaining good practice. But sometimes they’re a little too aggressive, and when the rules are being imported from elsewhere, I am not sure how to temporarily disable them.

This is especially frustrating when the linter decides it will break your shit instantly, so I found it easier to just call a method and remove it when the functionality is built.

Right now there’s at least 4 “this.stopBitchingAbout([all, the, things])” in my code.

I started my actual gig as CTO of construction group (Innovation Hub) a year ago. And it was a hell of a ride, implementing kind of a scrum-ban for project management, XP, peer-reviews, a git-flow, git commit message formats, linters, unit testing, integration tests, etc...
And it's the fun part because with the CIO we had to drive the board to do A LOT of changes in their IT/Innovation drive.

But in one year there is a lot of KPI that went up :
* Deployment: When I arrived it took three stressful days to deploy a new version of one application, once a month. Today we do it every week, and it takes three annoying hours.
* We had no test. NOTHING! Today we have 85% code coverage for the unit test, and automatic integration tests run by our CI server every day.
* We had almost no documentation. Today our code is our documentation (it automatically extracted and versioned).
* We had 0 add value in the use of git. With commit messages as "dev", "asked task", inside jokes and a lot of "fix" and "changes". Today we have a useful git, and we even use it to create our deploy changelogs (and it's only mildly annoying!).
* More important, the team is happy! They get their purpose, see betterment in their tech mastery. They started doing conception, applicative architecture, presentations, having fun.

There is still a LOT of bad things we are still working on, and trying to solve (support workflow and betterment). But seeing what they already did, I'm so proud of my TEAM! I'm a fucking asshole, workaholic, "just do it" kind of guy. But they managed to achieve so much. Fucking PROUD!!

Excessive usage of linters is harmful for your grammer.

>be intern me
>switch between JavaScript and python all day
>make some extra effort to comply with linters
>slowly forget how to write a for-loop block

Dev: linters can help us by keeping us focused on important problems.
Linter:

124:5 ✖ Expected indentation of 2 spaces indentation
[...]
150:5 ✖ Expected indentation of 2 spaces indentation
151:5 ✖ Expected indentation of 2 spaces indentation
152:5 ✖ Expected indentation of 2 spaces indentation
153:5 ✖ Expected indentation of 2 spaces indentation
154:5 ✖ Expected indentation of 2 spaces indentation
155:5 ✖ Expected indentation of 2 spaces indentation
156:5 ✖ Expected indentation of 2 spaces indentation
157:5 ✖ Expected indentation of 2 spaces indentation
158:5 ✖ Expected indentation of 2 spaces indentation
159:5 ✖ Expected indentation of 2 spaces indentation
160:5 ✖ Expected indentation of 2 spaces indentation
161:5 ✖ Expected indentation of 2 spaces indentation
162:5 ✖ Expected indentation of 2 spaces indentation
163:5 ✖ Expected indentation of 2 spaces indentation
164:5 ✖ Expected indentation of 2 spaces indentation
165:5 ✖ Expected indentation of 2 spaces indentation
166:5 ✖ Expected indentation of 2 spaces indentation
167:5 ✖ Expected indentation of 2 spaces indentation
168:5 ✖ Expected indentation of 2 spaces indentation
169:5 ✖ Expected indentation of 2 spaces indentation
170:5 ✖ Expected indentation of 2 spaces indentation
171:5 ✖ Expected indentation of 2 spaces indentation
172:5 ✖ Expected indentation of 2 spaces indentation
174:5 ✖ Expected indentation of 2 spaces indentation
175:3 ✖ Expected indentation of 0 spaces indentation

50 problems (50 errors, 0 warnings)

I get pissy when people don't use linters, then I just spent ages super confused why the data wasn't loading in my component, then realised I hadn't decorated my class and I've been ignoring the red underline for the past half hour.

Seriously need to follow my own advice.

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)

The rest of my team do code reviews like human linters (not very well). I love the look on their faces when I volunteer to review their changes.

I don't know if something changed on the go linters, the spec or whatever.

...... but I am so fucking glad that I don't get retarded "eXpoRteD FuNctioNs neeEd tO bE coMmenTed"

Fuck how I hate how these tools operate sometimes

We've got two conflicting linters for ruby.
The rubocops serve the IDE and say to outdent access modifiers, giving the indented line a little yellow under-squiggle. Monkey see, monkey do, I indent it.
The company's one in the build pipeline wants to indent access modifiers and literally fails the bloody build, screaming about a rogue access modifier two spaces from where it should be.
Waste of 5 minutes.

HOLY FUCK I never thought that using async websockets in Django 3.x will be THAT much pain in the ass...
Also my next contribution will be their docs for sure, the examples are so fucking bad (linters are crying and begging me to kill them)

Anyone else talk to their code linters? My coworkers have been confused as to why I keep cursing at my computer.

Even with auto prefixing and linters, css is always a headache when you have to support any version of Internet Explorer.

Images go to their original size, even with fixed width/height.
Nothing has changed.

A former team lead decided the team should review any open PR before proceeding with their own tasks after their breaks. Any open PR also meant reviewing refinements in an ongoing discussion. Several times, we wasted time for review, coding, and discussing when the second reviewer asked to revert the changes introduced according to the requests of the first reviewer.

Now as a freelancer, in smaller projects, I sometimes have no coworkers to review my code. So, apart from testing, I try to pay more attention to linters, static code analysis and automated coding assistance. I have stylelint, eslint, SonarLint, and possibly some more IDE inspections. For the infamous popular blogging software, I also have a so-called PHP code sniffer that checks all PHP and JavaScript code for compliance with the WordPress coding styles, so finally, I got the team experience back: SonarLint suggests removing unnecessary spaces and reformating my code, which in turn makes PHPCS complain that the code violates the legacy code style.

Dear Python linters, why can't any of you implement some actual linting features? Like, say, consistent use of single or double quotes? Or dict() vs {}? How about indenting nested function calls? Forcing list / set / dict literals as multiline? Trailing commas?

And while I'm at it, why can't you handle dependencies properly? Say, separating linter & linter plugins from the remaining dependencies in a way where I don't have to manually remove them from the requirements lockfile every time?

Once upon a time I spent a week writing down a "Coding Conventions" document, setting up linters for JavaScript & CSS based on those rules and put the call to the linter in our gulp build task, only to figure out the next day it was commented out by some guy because "the build task was throwing errors" due to his shitty coding style...

When you’re so sleep deprived from days with no sleep and you’re writing only a few lines every 30 minutes after overlooking linters and fixing syntax errors, but you need to get the work done **lid-pop**… Hate it but love it..

What do you guys think of forced linters (checkStyle) on java assignments?

At this University we have a submission system that checks for your code where if a line didn't match the coding specification then it's an instant zero.

Being experienced in programming before going to a university, this somewhat surprised me, it also has unit tests implemented in it where it checks against input and output.

Would love to hear your thoughts on this. Is it too much for people who unlike me never seen code before? Or let them have hell and understand how to deal with it? I personally think it's too much for beginners.

When you have a linter that runs as a pre-commit task.

The number of times I've fixed errors thrown by linters during a commit and then run `git commit` straight after only to realize I'd forgotten to add the files I modified for the linter fix.

Shitty legacy codebase made by shovelling pile of different shit by some 'cool dude' who left the company 3 years ago. Fixing bugs on this pile of shit all the time, but also I have to document everything as documentation wasn't there at all and fix the whole damn project in the meantime. No linters, no types, ancient libraries that have shitton of issues, hacky behaviours wherever you look, no tests whatsoever.

Except when we want to refactor/rewrite we don't get time for fixing the whole shit as it is worthless - there's no value for customers in that.

the other one was shitty HR talk which consisted of bashing on my technical competencies by computer illiterate troglodyte after which I left the company. They asked me could I stay for 2 more months.

That was that one single NO that felt so great that I will remember it for the rest of my life.

Atm we're merging everything straight up to production because we only have our first client going live tomorrow. No problem except for the fact boss is using production to give demos to clients already. And so some JavaScript change that broke search made it to production and cropped up during a demo. So what does boss do? Call HR/support and yell at her that everything which works needs to keep working. Which is fair if we were live and we go back to merging to production being rare. So HR/support was in tears during our meeting where we were taking about the new live branch structure. GG boss. We consoled HR/support but really boss man knew how we work but ignored it.

Question for everyone though: what can we use or do to prevent changes to more general JavaScript breaking things around the code? We talked about unit tests and maybe code linters but is there more? Because it seems now might be the time to improve our working and even get budgets for tools.

Frontend: $ vue init ducksoupdev/vue-webpack-typescript bodywork, setup some linters, formaters and ci and I'm ready to go
Backend: $ cargo new --bin gears, setup some linters, formaters and ci and I'm ready to go

I've not used linters on sublime text so far. And now struggling to find a good linter for sublime for writing React JS.

And I am not comfortable to move to atom or VSCode.

Can anyone suggest me some good linters?

I'm sorry, but who thought eslint or any linters for that matter were a good idea.

Started a new vue project using the cli, installed tailwind... oh what's that you don't like the line length... get out of here. It's an SVG and using a class-based framework. The hell.

Any way of removing eslint? I just want to code and not get bs warnings because of an svg length or because I add one to many classes.

Once a React aficionado, twice the frustration we endure,
In the realm of libraries, React's problems seem impure.
With Svelte's elegance and grace in our sight,
Let's vent about React, as day turns into night.

Boilerplate Overload, a monotonous affair,
Classes, constructors, lifecycle steps we declare.
In Svelte's simplicity, we find a breath of fresh air,
Just markup and magic – a coder's love affair.

Complex State Management, React's Achilles' heel,
Redux, Mobx, and their massive code appeal.
Svelte's state handling is a cinch, for real,
No more tangled webs of logic to conceal.

Unnecessary Re-Renders, React's performance woe,
Countless updates, like a never-ending show.
Svelte updates what's needed, like a pro,
Efficiency and speed, in its radiant glow.

Verbose Syntax, JSX's verbosity on display,
HTML in JavaScript, causing dismay.
Svelte's concise template syntax lights our way,
No more endless tags, just code that's here to stay.

Lack of Truly Reactive Behavior, React's hurdle high,
Hooks to wrangle, state to satisfy.
Svelte's reactivity, no need to question why,
It just works, oh my, oh my.

Ecosystem Complexity, React's sprawling sprawl,
Choices galore, making us bawl.
In Svelte's world, simplicity is the call,
A coherent ecosystem, it has it all.

Learning Curve, React's mountain to climb,
Classes, hooks, context, a hill of time.
Svelte's gentle curve feels sublime,
A smoother path to code, so fine.

Tooling Overkill, React's complex array,
Build tools, linters, configs in disarray.
Svelte's streamlined setup leads the way,
No more intergalactic code buffet.

Debugging Headaches, React's mysterious realm,
Complex state, intricate components overwhelm.
Svelte's predictable model, a soothing helm,
Debugging becomes a peaceful realm.

In the end, React, a complex labyrinth we explore,
Svelte's elegance and simplicity we adore.
If only React could learn, its problems to deplore,
A brighter future, for React we'd implore.

tell me guys what would you prefer:

function a(){
..
b(..)
..
b(..)
..
}
function b(p1,p2,p3,p4,p5,p6){.
...
}

or

function a(){
..
b(..)
..
b(..)
..
}

function b(
p1,
p2,
p3,
p4,
p5,
p6
){
...
}

if you read this rant before expanding, you got a complete context on how what function a is, its calling b 2 times and how function b looks.

if instead of the first option, i had used 2nd block, you wouldn't even know the 2nd param of b function without expanding this rant.

my point?
i prefer to keeping unnecessary info on one line. and w lot of linters disagree by splitting up the code. and most importantly , my arrogant tl disagree by saying he prefers the splitted code "for readability" and becaue "he likes code this way, old-eng1 likes this and old-eng2 likes this" .

why tf does an ide have horizontal a scrolling option available when you are too stupid to use it?

ok, i know some smartass is going to point that i too can use vertical scrolling, but hear me out: i am optimising this!

case 1 : a function with 7 params is NOT split into 7 lines. lets calculate the effort to remember it
- since all params could have similar charactersticks ( they will be of some type, might have defaults, might be a suspendable/async function etc), each param will take similar memory-efforts points. say 5sp each.
- total memory-efforts= 5sp *7 = 35 sp.
- say a human has 100 sp of fast memory storage, he can use the remaining 65 sp for loading say 5 small lines above or below.
- but since 5 lines above are already read and still visible on screen, they won't be needed to be loaded again nd again, nd we can just check the lines below.
- thus we are able to store 65+35+65 = 165 sp or about 11 lines of code in out fast memory for just a 100sp brain storage

case 2 function with 7 params IS split into 7 lines.
- in this case all lines are somewhat similar. 5sp for param lines as they are still similar which implies same 35sp for storing current function and params
- remaining 65sp can only be used to store next 5 lines of 13sp as the previous code is no longer visible.
- plus if you wanna refresh the code above, you gotta scroll, which will result in removing bottom code from screen , and now your 65sp from bottom code is overwritten by 65sp of top code.
- thus at a time, you are storing only 6 lines worth of code info. this makes you slow.

this is some imaginary math, but i believe it works

Javascript - VS code
Python - VS code (linters sometimes show weird errors)
Dart/Flutter - VS code
Debugging qa instance via eb ssh - Vim with vim cheat sheet opened in browser tab

Need advice about switching to contracting.

TL;DR;

So I had 2 years of exp as an android dev, then I had a 1.5 year gap from doing android and now for the past 6 months Ive been doing android again fulltime. Im thinking of switching to contracting due to my debts and boring project and life crushing slow corporate processes in my current fulltime job, so I need tips and advices as to where should I start looking for new contracting gigs and in general what should I pay attention to. If it helps, I am based in EU, but am open to any EU/US gigs.

Now the full story:

Initially when I joined my current fulltime job after a break I had zero confidence, lowered my and employers expectations, joined as a junior but quickly picked up the latest standards and crushed it. Im doing better than half devs in my scrum team right now and would consider myself to be a mid level right now.

Asked for a 50% bump, manager kinda okayed it but the HQ overseas is taking a very long time to give me the actual bump. I have been waiting for 10 weeks already (lots of people in the decision chain were on and off vacations due to summer, also I guess manager sent this request to HQ too late, go figure). Anyways its becoming unnaceptable and I feel like its time for a change.

Now since I have mortgage and bills to pay, even with the bump that I requested that would leave me with like maximum 700-800 bucks a month after all expenses. I have debts of around 20k and paying them back at this rate would take 3 years at least and sounds like a not viable plan at all.

Also it does not help that the project Im working on is full of legacy and Im not learning anything new here. Corporate life seems to be very slow, lots of red tape kills creativity and so on. I remember in startups I was cooking features left and right each sprint, in here deploying a simple popup feature sometimes takes weeks due to incompetence in the chain. I miss the times where I worked in startups, did my job learned nre skills and after 6 months could jump on another exciting gig. Im not growing here anymore.

So because my ADD brain seems to be suited much better for working in startups, and also I need to make more money quick and I dont see a future in current company, I am thinking of going back to contracting. All I need right now is to build a few side apps, get them reviewed by seniors and fill my knowledge gaps. Then I plan of starting interviewing as a mid level or even a senior for that matter, since I worked with actual seniors and to be honest I dont think getting up to their level would be rocket science.

Only difference between mid and senior devs that I see atleast in my current company is that seniors are taking on responsibility more often, and they also take care of our tools, such as CD/CI, pipeline scripts, linters and etc. Usually seniors are the ones who do the research/investigations and then come up with actual tasks/stories for mids/juniors. Also seniors introduce new dependencies and update our stack, solve some performance issues and address bottlenecks and technical debt. I dont think its rocket science, also Ive been the sole dev responsible for apps in the past and always did decent work. Turns out all I needed was to test myself in an environment full of other devs, thats it. My only bottleneck was the imposter syndrome because I was a self taught dev who worked most of my career alone.

Anyways I posted here asking for some tips and advices on how to begin my search for new contract opportunities. I am living in EU, can you give me some decent sites where I could just start applying? Also I would appreciate any other tips opinions and feedback. Thanks!