Do you follow test driven development?

Classes are classist.

Objects are objectifying.

Race conditions are racist.

Foreign keys are xenophobic.

Functions are ableist.

Thin clients are weightist.

Bitmasks perpetuate heteronormativity.

Code beautifiers promote unrealistic beauty expectations.

Test-driven development is victim blaming.

Forced commit pushes are rape.

Motherboards perpetuate gender roles.

And don't get me started on white space.

Looks like I'm getting fired on Wednesday :)

Long story:

*I add first unit tests to project.

*Boss adds new functionality and breaks all the tests so I can't compile and write more for what I'm working on.

*Boss is very fragile and cannot handle any comment that can possibly be taken as a slight against him.

Me: "I wanted to ask what our policy on unit tests is please? Because we haven't really said how we are treating unit tests, and everyone myself included is not thinking about them. I also haven't added tests when I fixed bugs and this time your changes broke the tests"

Boss 10 minutes later: "I want to speak to you in private".

Boss: "you are too forceful and direct. You said I should have added tests."

Me: "yeah but I didn't mean in a nasty way"

Boss getting louder and more aggressive: "You are too forceful"

Me: "I didn't mean it in a bad way"

Boss: "I didn't want to add tests for that!"

Me: "then why add any tests?"

Boss: "Fine we are not having this conversation now!"

*Boss storms out

I decided I can't speak to the guy about anything without upsetting him spoke to the manager before I quit because I can't work like this.

That resulted in a meeting with my boss, his boss and the head of HR where I ended up savaging him and told them I can't bring up anything as I can never tell if it will offend him and that I spend ages writing emails and trying to document communications because I just can never tell if I will upset him. Also that I cannot bring up any ideas because I can't tell if he will somehow get offended and that I can't even write code because if I change something he wrote at some point he will get angry.

My boss claims that I am extremely forceful and disrespectful and that I am constantly insulting him and his decisions.

We go back over a ton of shit and I refute everything he says. In the end I have to have a meeting with him on Wednesday where we either get things straight, he fires me or I quit.

I think at this point that our relationship is too fucked for him to be my team lead on a 6 man team.

Side note I keep bringing forth ideas because we have one database shared between 6 Devs, no pull requests (apart from mine and another new guy), no test driven development, no backlog, no team driven story pointing, no running tests before merging, no continuous integration setup, no integration tests, no build step on merge, no idea of if we are on track to our deadline other than his gut feeling, no actual unit tests backend - just integration with a test db, no enthusiasm to learn in the team and no hope.

overheard someone say "test driven development is essentially 'debugging a system into existence'"

.... And to be honest I can't disagree, it's quite an accurate description of TDD.

"Can you work on this ticket? It's kind of urgent."

-- "OK"

"And could you please not refactor? Just get this done."

-- "Why? What's the issue?"

"The logic is complex. We should not break it."

-- "Erm, that's what the tests are for. So yes, if the need arises, I'll refactor. The tests are my guidelines if the logic breaks or not."

There's a reason we create tests. So let's not hinder code base improvements by some random fear that stuff might break.

If breaks due to refactoring, we'll fix it by adding a valid test case during and then fixing the bug.

If my refactoring does not break the tests, I'll assume the code base is stable.

If your code is untested, then we have a complete different problem.

Let the student use their own laptops. Even buy them one instead of having computers on site that no one uses for coding but only for some multiple choice tests and to browse Facebook.

Teach them 10 finger typing. (Don't be too strict and allow for personal preferences.)

Teach them text navigation and editing shortcuts. They should be able to scroll per page, jump to the beginning or end of the line or jump word by word. (I am not talking vi bindings or emacs magic.) And no, key repeat is an antifeature.

Teach them VCS before their first group assignment. Let's be honest, VCS means git nowadays. Yet teach them git != GitHub.

Teach git through the command line. They are allowed to use a gui once they aren't afraid to resolve a merge conflict or to rebase their feature branch against master. Just committing and pushing is not enough.

Teach them test-driven development ASAP. You can even give them assignments with a codebase of failing tests and their job is to make them pass in the beginning. Later require them to write tests themselves.

Don't teach the language, teach concepts. (No, if else and for loops aren't concepts you god-damn amateur! That's just syntax!)

When teaching object oriented programming, I'd smack you if do inane examples with vehicles, cars, bikes and a Mercedes Benz. Or animal, cat and dog for that matter. (I came from a self-taught imperative background. Those examples obfuscate more than they help.) Also, inheritance is overrated in oop teachings.

Functional programming concepts should be taught earlier as its concepts of avoiding side effects and pure functions can benefit even oop code bases. (Also great way to introduce testing, as pure functions take certain inputs and produce one output.)

Focus on one language in the beginning, it need not be Java, but don't confuse students with Java, Python and Ruby in their first year. (Bonus point if the language supports both oop and functional programming.)

And for the love of gawd: let them have a strictly typed language. Why would you teach with JavaScript!?

Use industry standards. Notepad, atom and eclipse might be open source and free; yet JetBrains community editions still best them.

For grades, don't your dare demand for them to write code on paper. (Pseudocode is fine.)

Don't let your students play compiler in their heads. It's not their job to know exactly what exception will be thrown by your contrived example. That's the compilers job to complain about. Rather teach them how to find solutions to these errors.

Teach them advanced google searches.

Teach them how to write a issue for a library on GitHub and similar sites.

Teach them how to ask a good stackoverflow question :>

No matter how much product owners claim "bugs have priority over anything else", "we value high quality structured code", and "we do test driven development"...

...Once a big client wants a feature to be developed before they sign up, dirty code will be written from napkin specs, and that code will always be refractored "soon".

There are many ways of development...
Test Driven Development.
Behaviour Driven Development.
Acceptance-Test Driven Development.
YOLO Driven Development.

But nothing in this world is so frustrating as...
Buzzword Driven Development.

As soon as your managers spot a new technology, it needs to be integrated...
For fucks sake... New is not always better.

[long]
When searching for internship via school I found this small startup with this cute project of building a teaching tool for programming. There were back then 2 programmers: the founder and the co-founder.

Then like 1 week before the internship started, the co-founder had a burnout and had to get off the project, while the company was so low on budget the founder, aka my new b0ss, had to work separate jobs to keep the company alive. (quite metal tbh)

It's funny because I'm a junior developer, 100%. I've been coding as a hobby for around 8 years now but I've never worked in a big company before. (No exception to this workplace either)

First project I get: rewrite the compiler. The Python compiler.
"But wait, why not just embed a real compiler from the first case?"
-nanananana it's never simple, as you probably know from your own projects.

The new compiler, as compared to existing embedded compiler solutions out there, needed these prime features:
- Walk through the code (debugger style), but programmatically.
- Show custom exceptions (ex: "A colon is needed at the end of an if-statement" instead of "Syntax error line 3")
- Have a "Did-you-mean this variable?" error for usage of unassigned variables.
- Be able to be embedded in Unity's WebGL build target

All for the use case of being a friendly compiler.
The last dash in the list is actually the biggest bottleneck which excluded all existing open-source projects (i could find). Compliant with WebAssembly I can't use threads among other things, IL2CPP has lots of restrictions, Unity has some as well...

Oh and it should of course be built using test-driven development.

"Good luck!" - said the founder, first day of work as she then traveled to USA for **3 weeks**, leaving me solo with the to-be-made codebase and humongous list of requirements.

---

I just finished the 6th week of internship, boss has been at "HQ" for 3 weeks now, and I just hit the biggest milestone yet for this project.

Yes I've been succeeding! This project has gone so well, and I'm surprising myself how much code I've been pumping out during these weeks.

I'm up now at almost 40'000 lines of source and 30'000 lines of code. ‼
( Biggest project I've ever worked on previously was at 8'000 lines of code )

The milestone (that I finished today) was for loops! As been trying to showcase in the GIF.

---

It's such a giant project and I can honestly say I've done some good work here. Self-five. Over-performing is a thing.

The things that makes me shiver though is that most that use this application will never know the intricates of it's insides, and the brain work put into it.

The project is probably over-engineered. A lot. Having a home-made compiler gives us a lot of flexibility for our product as we're trying to make more of a "pedagogic IDE". But no matter that I reinvented the wheel for the 105Gth time, it's still the most fun I've had with a project to date.

---

Also btw if anyone wants to see source code, please give me good reasons as I'm actively trying to convince my boss to make the compiler open-source.

Cheers!

finally started test driven development

Friend of mine: so I wonder how do you test your applications in the startup?

Me: testing? *grabs his coffee laughing*

Actually we have a complete build pipeline from commit/pull-request to dev and production environments. No tests. Really. We are in rapid product development / research state.

We change technologies and approaches like our underwear (and yeah, this is frequently). If we settled some day and understood the basic problems of the whole feature palette, we'll talk about tests again.

I love Test-Driven Development!

And because of that fact, my heart shatters into thousands of pieces, when I recognize error events on our production nodes which are pointing onto a golden hammer function in a legacy project.

This particular function has about 300 lines with a bunch of subfunction calls and instantiations of helper-classes returning information for workflow.

Refactoring this code to apply proper unit-tests requires a way bigger investment than simply deal with 30 eventlogs a day, because this kind of payment is barely used by customers of our webshop.

This fact is a little itch each day of my work.

Guess it will make me go insane one day
¯\_(ツ)_/¯

xD

Apparently the fire hose in our building wasn't connected to the water main, because the legislation stated the building owner had to install a fire hose, not connect a fire hose to the water main.

Fucking non technical managers and their shitty clients to whom they suck their tiny weiners need to realise that I cannot reorder elements every 10 minutes to the shape of their fart comming out of their ass, test it, deploy it, trigger webhook, clear cloudflare cache, and meanwhile be sure that it's written in quality manner for future upkeep with commits that have sense.Hope deadline driven development dies in hell where it belongs

Test-driven development

STOP WRITING CRAZY FUNCTIONS FULL OF INSTANTIATIONS THAT I NOR ANYONE WILL EVER BE ABLE TO WRITE UNIT TESTS FOR!!! STOP calling static factory methods that spawn up who knows what in mid function as if Im actually going to be able to mock such a dependency. Better yet, practice test driven development so we don't end up in this mess again

Working out how to continue an interview when the interviewee thinks Test Driven Development is fixing bugs raised by the Test Team

Guys...

It has come this far...

I... I like test driven development and the amount of unit tests and security it gives you. And I kinda laugh at people that don't take unit testing seriously :p

I am about to try TDD for embedded C. Does anyone around here tried that? What are your experiences with it? Thanks!

So I started working at a large, multi billion dollar healthcare company here in the US, time for round 2,(previously I wasn't a dev or in IT at all). We have the shittiest codebase I have ever laid eyes on, and its all recent! It's like all these contractors only know the basics of programming(i'm talking intro to programming college level). You would think that they would start using test driven development by now, since every deployment they fix 1 thing and break 30 more. Then we have to wait 3 months for a new fix, and repeat the cycle, when the code is being used to process and pay healthcare claims.

Then some of my coworkers seem to have decided to treat me like I'm stupid, just because I can't understand a single fucking word what they're saying. I have hearing loss, and your mumbling and quiet tone on top of your think accent while you stop annunciated your words is quite fucking hard to understand. Now I know english isn't your first language and its difficult, I know, mine is Spanish. But for the love of god learn to speak the fuck up, and also learn to write actual SQL scripts and not be a fucking script kiddie you fucking amateur. The business is telling you your data is wrong because you're trying to find data that exists is complex and your simple select * from table where you='amateur with "10years" experience in SQL' ain't going to fucking cut it. Learn to solve problems and think analytically instead of copy fucking pasta.

BI guys ask us to avoid deploy on Fridays cause they don't have time to fix their stuff.

"We cannot test until it is live..." They said.

I hate guys who prefer production driven development.

I really need to get out of this clusterfuck of a mess I got into, A.K.A. our website projects. Now, it feels more and more like all these problems and issues we're having are all my fault.

Here's the thing: I had 0 experience on web development before I got this job. I started as an intern, expecting to learn all the right practices and techniques on building websites. Nope. What happened was I was thrown in this big project, responsible for almost every functionality that it was supposed to have.

A junior-level guy. Doing a huge project on his own. Hell, I'm probably even lower than a junior. But here I am, pigeonholed in this shittard. My boss even said to me, "you know more about the website than I do." Fucking hell. He's not even aware of the clusterfucks I've done on the codebase because, fuck, what did I know? I don't even get feedbacks about my code. I don't fucking know if I'm doing all of these shit right. I don't know if this function is supposed to be here, or if it's supposed to behave that way, and, shit, the concept of test-driven development is probably something my boss has never heard of before.

So right now, I'm a bit obsessed with web development best practices, and how to write clean, maintainable code. I would probably get more learning from going to meetups than I will ever have from this place.

This has been a very shitty start of my career. I hope a much better learning experience will be plentiful at my next job (if anyone's willing to hire me). It would be like starting all over again. Sorry for the long post. I would like to put this as a blog post, but it's probably not a good idea, specially since I'm looking for a new job. Thank God for devRant.

Ok, so I need some clarity from you good folk, please.

My lead developer is also my main mentor, as I am still very much a junior. He carved out most of his career in PHP, but due to his curious/hands-on personality, he has become proficient with Golang, Docker, Javascript, HTML/CSS.

We have had a number of chats about what I am best focusing on, both personally and related to work, and he makes quite a compelling case for the "learn as many things as possible; this is what makes you truly valuable" school of thought. Trouble is, this is in direct contrast to what I was taught by my previously esteemed mentor, Gordon Zhu from watchandcode.com. "Watch and Code is about the core skills that all great developers possess. These skills are incredibly important but sound boring and forgettable. They’re things like reading code, consistency and style, debugging, refactoring, and test-driven development. If I could distill Watch and Code to one skill, it would be the ability to take any codebase and rip it apart. And the most important component of that ability is being able to read code."

As you can see, Gordon always emphasised language neutrality, mastering the fundamentals, and going deep rather than wide. He has a ruthlessly high barrier of entry for learning new skills, which is basically "learn something when you have no other option but to learn it".

His approach served me well for my deep dive into Javascript, my first language. It is still the one I know the best and enjoy using the most, despite having written programs in PHP, Ruby, Golang and C# since then. I have picked up quite a lot about different build pipelines, development environments and general web development as a result of exposure to these other things, so it isn't a waste of time.

But I am starting to go a bit mad. I focus almost exclusively on quite data intensive UI development with Vue.js in my day job, although there is an expectation I will help with porting an app to .NET Core 3 in a few months. .NET is rather huge from what I have seen so far, and I am seriously craving a sense of focus. My intuition says I am happiest on the front end, and that focusing on becoming a skilled Javascript engineer is where I will get the biggest returns in mastery, pay and also LIFE BALANCE/WELLBEING...

Any thoughts, people? I would be interested to hear peoples experiences regarding depth vs breadth when it comes to the real world.

Who else works at a company that enforces test driven development? And after doing TDD do you think you could ever go back to NOT doing TDD?

So much has happened, I've been learning things, I got robbed, I discovered I love test driven development, my laptop fell downstairs and is now screenless, I'm still on this project and still have not gotten the source or gone live, side work exists though so I get to make some more money, car engine needs to be overhauled, project extended still not in production. Send Help.

Trying to convince the class that test-driven development + DTSTTMPW ("do the simplest thing that might possibly work") + pair programming is the way to go, our software dev prof had us split in groups of two that would each get a turn to
1. add a unit test
2. edit the code so it passes the test
3. commit the change

The goal was to write a java class that converts integers to roman numerals.
Each group had only 2 minutes before the prof made them revert their changes.
After 45 minutes the code was just 10 lines of this:
if ( n == 1 )
return "I";
else if ( n == 2 )
return "II";
else if ( n == 3 ) ...

I really really hope that no one post this,a friend texted it to me and I wanted to share it because made my day.

Idk where it comes, so feel free if know where this came from to post it:

//FUN PART HERE
# Do not refactor, it is a bad practice. YOLO

# Not understanding why or how something works is always good. YOLO

# Do not ever test your code yourself, just ask. YOLO

# No one is going to read your code, at any point don’t comment. YOLO

# Why do it the easy way when you can reinvent the wheel? Future-proofing is for pussies. YOLO

# Do not read the documentation. YOLO

# Do not waste time with gists. YOLO

# Do not write specs. YOLO also matches to YDD (YOLO DRIVEN DEVELOPMENT)

# Do not use naming conventions. YOLO

# Paying for online tutorials is always better than just searching and reading. YOLO

# You always use production as an environment. YOLO

# Don’t describe what you’re trying to do, just ask random questions on how to do it. YOLO

# Don’t indent. YOLO

# Version control systems are for wussies. YOLO

# Developing on a system similar to the deployment system is for wussies! YOLO

# I don’t always test my code, but when I do, I do it in production. YOLO

# Real men deploy with ftp. YOLO

So YOLO Driven Development isn’t your style? Okay, here are a few more hilarious IT methodologies to get on board with.

*The Pigeon Methodology*
Boss flies in, shits all over everything, then flies away.

*ADD (Asshole Driven Development)*
An old favourite, which outlines any team where the biggest jerk makes all the big decisions. Wisdom, process and logic are not the factory default.

*NDAD (No Developers Allowed in Decisions)*
Methodology Developers of all kinds are strictly forbidden when it comes to decisions regarding entire projects, from back end design to deadlines, because middle and top management know exactly what they want, how it should be done, and how long it will take.

*FDD (Fear Driven Development)*
The analysis paralysis that can slow an entire project down, with developments afraid to make mistakes, break the build, or cause bugs. The source of a developer’s anxiety could be attributed to a failure in sharing information, or by implicating that team members are replaceable.

*CYAE (Cover Your Ass Engineering)*
As Scott Berkun so eloquently put it, the driving force behind most individual efforts is making sure that when the shit hits the fan, you are not to blame.

Personal Challenge of the day:
Write an entire complex react component (think a form with internal dialogs and cross component functionality) without testing once. Attempt to build the entire piece with all functionality without looking at the screen.

Ive been doing these little personal challenges with front end and backend assignments.

Ive noticed the difference its made in my daily work as I grow less dependent on the time consuming habit of checking browser/terminal feedback in order to determine what to do next.

With that I know people enjoy test driven development now days and thats a different story entirely. Not something I enjoy at all but I have no faults with the concept.

Test Driven Development, Pattern Driven Development, Domain Driven Development, Design Domain Driven Development.

When do we eventually get to the development part??

- One of the reasons for test driven development is that human makes errors. Both in developing the software and in testing it. So it's cheaper and safer to let computers do the test.
- So... who's going to develop the tester software itself?
- Human!

2nd week at my first job after I got my papers and what am I doing?

Background:
I followed a course of three years where all we learnt was web development with php and javascript. I of course wanted more and spend hours after school learning as much as a could without any help from others.

About the course:
We learn to tinker with code (php, javascript).
There was never a mention of design patterns.
We never got to know about TDD (test driven development).

Now:
Got the papers, found a job as a c# junior development and am currently working on a C# .NET web app using azure cloud and high standards using unit tests to provide a product for the awesome company I work at which should generate a stable income.

Tldr;
Hard work pays off.

Picked up the latest version of Test Driven Development work Python. Haven't done much test driven development so time to change that .

!rant

I would like to pick up some Test Driven Development practices. So that the most people benefit: "What book/material would you suggest for each language?"

So that I also benefit: I was hoping to find some books on C#, but some of the reviews gave me doubts.

Best thing about being a dev? Getting that precious green bar during test-driven development!

That feeling you get when starting a new scala project. Fresh start! Lessons I have learned:
1) Add a linting tool before the code gets inconsistent to the point where it has thousands of style errors.
2) use test driven development from the start so that refactoring later is a breeze.
3) Write top down, no matter how much I want to implement the algorithms first.
4) write the tests first!