Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "tests are important"
The university system is fucked.
I've been working in this industry for a few years now, but have been self taught for much longer. I'm only just starting college and I'm already angry.
What does a college degree really mean anymore? From some of the posts I've seen on devRant, it certainly doesn't ensure professional conduct, work ethic, or quality (shout out to the brave souls who deal with the lack of these daily). Companies should hire based on talent, not on a degree. Universities should focus more on real world applications or at least offer such programs for students interested in entering the workforce rather than research positions. A sizable chunk of universities' income (in the U.S. at least) comes from research and corporate sponsorships, and educating students is secondary to that. Nowadays education is treated as a business instead of a tool to create value in the world. That's what I signed up for, anyway - gaining the knowledge to create value in the world. And yet I along with many others feel so restricted, so bogged down with requirements, fees, shitty professors, and shitty university resources. There is so much knowledge out there that can be put to instant practical use - I am constantly shocked at the things left out of my college curriculum (lack of automated tests, version control, inadequate or inaccurate coverage of design patterns and philosophies) - things that are ABSOLUTELY essential to be successful in this career path.
It's wonderful that we eventually find the resources we need, or the motivation to develop essential skills, but it's sad that so many students in university lack proper direction through no fault of their own.
Fuck you, universities, for being so inflexible and consistently failing to serve your basic purpose - one of if not the most important purpose on this earth.
Fuck you, corporations, for hiring and paying based on degree. Fuck you, management, for being so ignorant about the industry you work in.
Fuck you, clients, who treat intelligent people like dirt, make unreasonable demands, pull some really shady shit, and perpetuate a damaging stereotype.
And fuck you to the developer who wrote my company's antipattern-filled, stringy-as-all hell codebase without comments. Just. Fuck you.15
At one of my former jobs, I had a four-day-week. I remember once being called on my free Friday by an agitated colleague of mine arguing that I crashed the entire application on the staging environment and I shall fix it that very day.
I refused. It was my free day after all and I had made plans. Yet I told him: OK, I take a look at it in Sunday and see what all the fuzz is all about. Because I honestly could fathom what big issue I could have caused.
On that Sunday, I realized that the feature I implemented worked as expected. And it took me two minutes to realize the problem: It was a minor thing, as it so often is: If the user was not logged in, instead of a user object, null got passed somewhere and boom -- 500 error screen. Some older feature broke due to some of my changes and I never noticed it as while I was developing I was always in a logged in state and I never bothered to test that feature as I assumed it working. Only my boss was not logged in when testing on the stage environment, and so he ran into it.
So what really pushed my buttons was:
It was not a bug. It was a regression.
Why is that distinction important?
My boss tried to guilt me into admitting that I did not deliver quality software. Yet he was the one explicitly forbidding me to write tests for that software. Well, this is what you get then! You pay in the long run by strange bugs, hotfixes, and annoyed developers. I salute you! :/
Yet I did not fix the bug right away. I could have. It would have just taken me just another two minutes again. Yet for once, instead of doing it quickly, I did it right: I, albeit unfamiliar with writing tests, searched for a way to write a test for that case. It came not easy for me as I was not accustomed to writing tests, and the solution I came up with a functional test not that ideal, as it required certain content to be in the database. But in the end, it worked good enough: I had a failing test. And then I made it pass again. That made the whole ordeal worthwhile to me. (Also the realization that that very Sunday, alone in that office, was one of the most productive since a long while really made me reflect my job choice.)
At the following Monday I just entered the office for the stand-up to declare that I fixed the regression and that I won't take responsibility for that crash on the staging environment. If you don't let me write test, don't expect me to test the entire application again and again. I don't want to ensure that the existing software doesn't break. That's what tests are for. Don't try to blame me for not having tests on critical infrastructure. And that's all I did on Monday. I have a policy to not do long hours, and when I do due to an "emergency", I will get my free time back another day. And so I went home that Monday right after the stand-up.
Do I even need to spell it out that I made a requirement for my next job to have a culture that requires testing? I did, and never looked back and I grew a lot as a developer.
I have familiarized myself with both the wonderful world of unit and acceptance testing. And deploying suddenly becomes cheap and easy. Sure, there sometimes are problems. But almost always they are related to infrastructure and not the underlying code base. (And yeah, sometimes you have randomly failing tests, but that's for another rant.)9
I work for a company that develops a variety of software solutions for companies of varying sizes. The company has three people in charge, and small teams that each worked on a certain project. 9 months ago I joined the company as a junior developer, and coincidentally, we also started working on our biggest project so far - an online platform for buying groceries from a variety of vendors/merchants and having them be delivered to your doorstep on the same day (hadn't been done to this scale in Estonia yet). One of the people from management joined the team working on that. The company that ordered this is coincidentally being run by one of the richest men in Estonia. The platform included both the actual website for customers to use, a logistics system for routing between the merchants, the warehouse, and the customers, as well as a bunch of mobile apps for the couriers, warehouse personnel, etc. It was built on Node.js with Hapi (for the backend stuff), Angular 2 (for all the UIs, including the apps which are run through a WebView wrapper), and PostgreSQL (for the database). The deadline for the MVP we (read: the management) gave them, but we finished it in about 7 months in a team of five.
The hours were insane, from 10 AM to 10 PM if lucky. When we weren't lucky (which was half of the time, if not more), we had to work until anywhere from 12 PM to 3 AM, sometimes even the whole night. The weekends weren't any better, for the majority of the time we had to put in even more extra hours on the weekends. Luckily, we were paid extra for them, but the salary was no way near fair (the majority of the team earned about 1000€/mo after taxes in a country where junior developers usually earn 1500€/month). Also because of the short deadline given to us, we skipped all the important parts like writing tests, doing CI, code reviews, feature branching/PR's, etc. I tried pushing the team and the management to at least write tests and make feature branches/PRs, but the management always told me that there wasn't enough time to coordinate and work on all that, that we'll do that after launching the MVP, etc. We basically just wrote features, tested them by hand, and pushed into the "test" branch which would later get tested and merged into master.
During development, one of the other juniors managed to write the worst kind of Angular code you could imagine - enormous amounts of duplication, no reusable components (every view contained the everything used in the view, so popups and other parts that should logically be reusable were in every view separately), fuck - even the HTML was broken (the most memorable for me were the "table > tr > div > td" ones, but that's barely scratching the surface). He left a few months into the project, and we had to build upon his shit, ever so slightly trying to fix the shit he produced. This could have definitely been avoided if we did code reviews.
A month after launching the MVP for internal testing, the guy working on the logistics system had burned out and left the company (he's earning more than twice the salary he got here, happy for him, he is a great coder and an even better team player). This could have been avoided if this project had been planned better, but I can't really blame them, since it was the first project they had at this scale (even though they had given longer deadlines for projects way smaller than this).
After we finished and launched the MVP, the second guy from management joined, because he saw we needed extra help. Again I tried to push us into investing the time to write tests for the system (because at this point we had created an unstable cluster fuck of a codebase), but again to no avail. The same "no time, just test it manually for now, we'll do that later when we have time" bullshit from management.
Now, a few weeks ago, the third guy from management joined. He saw what a disaster our whole project was. Him joining was simply a blessing from the skies. He started off by writing migrations using sequelize. I talked to him about writing tests and everything, and he actually listened. He told me that I'm gonna be the one writing them, and also talked to the rest of management about it. I was overjoyed. I could actually hear the bitterness in the voices of the rest of management when they told me how to write the tests, what to test, etc. But I didn't give a flying rat's ass, I was hapi.
I was told to start off by writing a smoke test for the whole client flow using Puppeteer. I got even happier, since I was finally able to again learn new things (this stopped at about 4 or 5 months into the project).
I'm using jest as the framework and started writing the tests in TypeScript. Later I found a library called jest-extended, but it didn't have type defs, so I decided to write them and, for the first time in my life, contribute to the open source community.20
I've found sites like Udemy/Khanacademy/Codecademy/Brilliant/Edx to be very useful — possibly more useful than expensive education.
But they still need:
1. Better correction/update mechanisms. Human teachers make mistakes and material gets outdated, and while online teachers are rectified faster than classroom teachers, the procedure is still not optimal. Knowledge should be a bit more like a verified wiki.
2. Some have great interactive coding environments, some have great videos, some have awesome texts, some have helpful communities. None has it all. In the end, I don't want to learn a new language by writing code in my browser. It could all be integrated/synced to the point where IDEs have plugins which are synced to online videos, with tests and exercises built in, up to a social network where you could send snippets for review and add reviews to other people's code.
3. Accreditation. Some platforms offer this against payment, but I think those platforms often feel very old school (pun intended), with fixed schedules, marks and enrollments. Self paced is a must.
4. Depth is important. Current online courses are often a bit introductory. We need more advanced courses about algorithms, theoretical computer science, code design, relational algebra, category theory, etc. I get that it's about supply/demand, but we will eventually need to have those topics covered.
I do believe that for CS, full online education will eventually win from the classroom — it's still in its infancy, but has more potential to grow into correct, modern education.10
Casual workday be like:
Project manager: It is important we deliver these features.
Me & Coworker: Sounds reasonable, here is how long we need, roughly.
Mgr: Well, the deadline is already set and the contract is signed and written.
Mgr: Also, while we are hosting the application, we are not paid for operational cost, so make sure to optimise the crap out of it immediatly. Preferably while developing the features.
(A wild architect appears): Also everything has to be built on cans and kubernuts, with rectangular ui and bootstyling and with these internally developed backend frameworks NOBODY tests. Coroporate policy you know.
(A wilder division CEO appears on meeting): Also we are rolling out code KPI's across the organisation. Everyone is expected to Focus on documentation, test coverage and there is now mandatory SonarQube scanning of repos. ZERO DEFECTS PEOPLE
(Wildest Salesteam appears): By the way we sold the application to these other customers, they love feature XYZ and must have it.
M&C: It does not have feature XYZ
Mgr: It will have feature XYZ
M&C: Allright so with all the extra funding from the sales, we need to hire atleast one Machine learning guy, an extra frontend specialist a developer and maybe funnel some of the funding into slacking the operational budget in the start.
Animated Suit *Railing a line of coke from his gold plated ihpone 15*: What funding? Get to work. Also your havent been super sharp with your time registration.2
(Best read while listening to AEnima by Tool, loudly)
Dear Current Workplace,
Fuck you, for the reasons enumerated below.
Fuck your enterprise grey blue offices, the stifling warm air of a hundreds of bodies and sub par "development laptops".
Fuck your shitty carbonated water machines which were a cost saving measure over decent drinkable water.
Fuck your fake "flexi time", "you can do home office whenever you want" bullshit. You're still inviting me to mandatory meetings at 09:00 regularly.
Fuck your shitty, in house, third part IT provider sister company. They're the worst of all worlds. If it was in company, we'd get to give out to them, if it was an external company we'd fire them. And yes, when I quit I will quote the dumpster fire that is our corporate VPN as a major factor.
Fuck your cheery, bland, enterprise communication. Words coming under the corporate letterhead seem to lose all association with meaning. Agile, communication, open are things you write and profess to respect, but it seems your totally lack understanding of their meaning.
Fuck your client driven development. Sometime you actually have to fix the foundations before you can actually add new features. And fuck you management who keep on asking "why are there so many bugs and why is it always taking longer to deliver new releases". Because of you, you fucknuts, Because you can't say "NO" to the customer. Because you never listen to your own experienced developers.
Fuck your bullshit "code quality is important to us" line. If it's so important, then let us fix the heap of shit you're selling so that it works like a quasi functional program.
Fuck you development environment which has 250 projects in a single VS solution. Which takes 5mins plus to compile on a quad core i7 with 32 gb of ram.
Fuck this bullshit ball of mud "architecture". I spend most of my time trying to figure out where the logic should go and the rest of the time writing converters between different components. All because 7 years ago some idiot "architect" made a decision that they didn't have to live with.
Actually, fuck that guy in particular. Yeah, that guy who was the responsible architect for the project for 4 years and not once opened the solution to look a the code.
Fuck the manual testing of every business process. Manual setup of the entities takes 10mins plus and then when you run, boom either no message or some bullshit error code.
Fuck the antiquated technology choices which cause loads of bugs and slow down development. Fuck you for forcing me to do manual tests of another developers code at 20:00 on a Friday night because we can't get our act together to do this automatically.
Fuck you for making sure it's very clear I'm never going to be anything but a code monkey in this structure. Managers are brought in from outside.
Fuck you for being surprised that it's hard to hire competent developers in this second rate, overpriced town. It's hard to hire anywhere but this bland shithole would have anyone with half a clue running away at top speed.
Fuck you for valuing long hours and loyalty over actual performance. That one guy who everyone hated and was totally incompetent couldn't even get himself fired. He had to quit.
Fuck you for your mediocrity.
Fuck you for being the only employer for my skill-set in the region; paying just well enough that changing jobs locally doesn't make sense, but badly enough that it's difficult to move.
Fuck you for being the stable "safe" option so that any move is "risky".
Fuck your mediocrity.
Fuck you for being something I think about when I'm not at work. Not only is it shit from 9 to 5 you manage to suck the joy out of everything else in my life as well?
Fuck you for making me feel like a worse developer every day I work here. Fuck you for making every day feel like a personal and professional failure. Fuck you for making me seriously leave a career I love for something, anything else.
Fuck you for making the most I can hope for when I get up in the morning is to just make it until the night.6
Happens every day:
"could you please fix those bugs ASAP? Testers are waiting for it"
*resolve the issue and inform the requester*
(two weeks later)
"Thanks, I'll inform the testers they can begin their tests"
Ugh, how ASAP makes everything seem so urgent and important
Oh, my boss never fails to amaze me...
Every fucking time he talks about changes to someone outside the team he says something like:
"we always gotta be prepared for breaks because it is always like that, you change something here and when you see you broke something there"
All in a manner that *tries* to bring tensions down.
And every time I explain to him why the fuck automated tests are important and wtf they do he always manage to understand it as a waste of time...
I'm never gonna give up, motherfucker.2
A discussion about writing tests for frontend applications.
Context: my frontend coworkers don't write tests, at all. Yeah, really. Our testing process is very manual. We test manually when developing. We test manually when reviewing code. After merging, the application is deployed to a staging server and the design team does a QA Sprint. Lots of manual testing and some bugs still crawl by.
So I decided to start pushing my coworkers to start writing tests. One of the reasons I constantly hear them say to not write tests in the frontend is: "It's not worth the time, because design keeps changing, which means we have to take time to fix the tests. Time that we usually don't have."
I've been thinking about this a lot and it seems to me that this is more related to bad tests than to tests in general.
Tests should not break with design changes (small changes at least). They should test funcionality, not how things look. A form should not break if the submit button's style changes, so why should its tests fail? I also think that tests help save time, as they prevent some back and forth because of bugs.
Writing good tests is the hard part. Tests that cover what's really important and aren't frail and break with things that shouldn't break them. What (and how) should we test? And what shouldn't be tested?
Writing them fast is another hard thing. Are you doing it right if they take more time to write than the actual code?
What do you think about this? Do you write tests for your frontend applications? What do you test? How much time do you spend writing tests? What are your testing tools/frameworks?6
Why is source code so crappy? May career is not the longest, buy in my 8 years I talked to so many developers and every one told me how important quality, standards, tests and architecture are - but every codebase I've seen is lacking all of it. Everything is running on constant live support.
I don't get it. It is like I live in a world where everyone does know what has to be done, but no-one does it. I suspect it is because people are lazy, lying and won't say no but that's also not a world I want to live in.24
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!!
My matryoshka keeping me company, because of course when you are alone testing a last hour deployment. shit will happen6
I really want to stress that we should add the ticket for adding the missing test cases in *this* sprint and not postpone it any further.
-- "Isn't there something more important to be added instead?"
There. ALWAYS. Is. Something. MORE. Important. The real problem was that we implement the test cases in the past to begin violating our definition of done. We have to fix and one point and we have to own that decision as nobody else will care about passing tests and test coverage. It's our job to care for that.
Yes, we can instead focus on all the other high-priorities task that should have been done yesterday, yet that won't change the fact that large part our codebase will remain an untested messy blackbox just asking for weird bugs and wild goosechases in the future.
Don't hide behind "high priority tasks". A job is done when it is fucking done and tests are part of that. Hurrying from one important task to the next will just mean we'll never do it. There is no better time than right now.
If code coverage got left behind in the past, then we'll have to suck it up in order to fix it as soon as possible, otherwise we'll just suck forever.1
Overengineering. Finding the right point between overdesign and no design at all. That's where fancy languages and unusual patterns being hit by real world problems, and you need to deal with all that utter mess you created being architecture astronaut. Isn't that funny how you realize that another fancy tool is fundamentally incompatible with the task you need to solve, and you realize it after a month of writing workarounds and hacks.
But on the other hand, duct tape slacking becomes a mess even quicker.
Not being able to promote projects. You may code the shit out of side project and still get zero response, absolutely no impact. That's why your side projects often becomes abandoned.
Oversleeping. You thought tomorrow was productive day, but you wake up oversleeped, your head aches, your mind is not clear and you be like "fuck that, I'm staying in bed watching memes all day". But there's job that has to be done, and that bothers you.
Writing tests. Oh, words can't describe how much I hate writing tests, any kind of. I tried testing so many times in high school, at university, even at production, but it seems like my mind is just doesn't accept it. I know that testing is fundamentally important, but my mind collapses every time I try to write a single fucking test, resulting in terrible headache. I don't know why it's like that, but it is, and I better repl the shit out of pure function than write fucking tests.
Objective-C is an awful programming language that nobody should ever use for anything.
Also you dont know how important unit tests are until you have to deliver an enterprise level application without them.
Biggest one Ive learned recently, managers will promise you the earth to keep you around as long as possible, and they will go back on every promise and call it a "change in priority"
I have a co-worker who won’t stop “refactoring” our codebase. He will go on a long tangent — under the guise of working on a proper story — and then reveal proudly after a few days that he now introduced a new middle-layer into the code which will help us such and such.
I have never seen any benefit from this. I think sometimes cleaning up variable names is nice, but a lot of the things just add noise and complexity. He’s a junior dev, I’m a senior dev. My progressional opinion is that he is doing a bad job. Management doesn’t know the full extent and the lead programmer scolds him every now and then but in the end let’s the code changes pass code review. “It has already been implemented so what’s the harm”.
Then the rest of us are stuck with horrible merge conflicts. I recently noticed that some new business-important unit tests that I wrote were mysteriously gone. Oops — lost in some misguided refactoring I guess. I’m assuming they were failing after the refactor, so clearly they had to go... Fortunately the underlying logic still works I think.
His main tactic in all of this seems to be to just use argumentative stamina. He will lose discussion after discussion but doesn’t seem to care. He’ll just talk and talk. And the in the end the lead tech gives in. And/or doesn’t have the energy to catch the error introduced.
I swear, the company would be better off without him. Maybe even better if we keep paying him but he just cleans the toilets instead. Sometimes I almost believes he gets up in the morning to come to work and just fuck with people all day.2
I need to add new feature into the program which I wrote years ago so I start digging up the source code. The project is written in a language which I no longer code in.
That code is really poorly written with most of them don't have tests. I also find out that previous self is really a genius since he can keep track of huge project with almost no documentation.
To make matter worst, there are unused components (class,feature) in the source code. "Current me" have a policy of "just adding only a feature you need and remove unused feature" but it seem the "previous me" don't agree with the "current me".
The previous me also have the habit of using writing insane logic. I can remember what particular class and methods is doing but I can't figure out the details.
For example one method only have 5 line of code but it is very hard to figure out what those do.
The saving grace is that he know the important for method signature and using immutable data structure everywhere.
I was under the influence of caffeine and have a constant sleep deprivation at the time (only sleeping about 4 hour every day) so I can't blame him too hard.
I can't blame him too hard, right?
Could someone invent a time machine already? Invent time machine not to save the world but to save the developers from himself.5
Any code should be simple and easy to read / understand.
I just reworked an old stored SQL proc.
Went from 102 lines to ... 10.
More I code, more I realize that maintainability, readability, comments and unit tests are more important than actual code. (And performances ofc. But if 1 line code does it in 1 second and 500 lines code in 0.2 seconds, I’ll take one line solution every time)5
Today I read a great article on mutation tests, how to use and why they are important. It looks like a great thing, but...
I have never wrote any unit test in any of my jobs. Nobody in my workplace does that. And now it seems like 100% test coverage is not enough (I remind you, that I have 0%), they all should mutate to check if the quality of unit tests is high.
It seems that I'm left behind. I played with tests in my free time, but it seems the more you write them, the better you get at it, so I should be writing them in my job, where I code most of my time. Not only that, of course, I would also want to ensure that what I'm working on is bug-free.
Still, it will be impossible to introduce unit tests to my project, because they are novelty to the whole team and our deadlines are tight. The other thing is, we are supposed to write minimum viable product, as it is a demo for a client, and every line of code matters. Some might say that we are delusional that after we finish demo we will make things the right way.
Did any one of you have a situation like this? How did you change your boss and team's mind?8
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.
This is why we can never have enough software developers
It's true. No matter how many people learn to program, there will never be enough people who know how to program. They don't have to be very good at it either. It is now a required skill.
Minimum wage in first world countries is way above 5$ per hour. A Raspberry PI 3B costs 40$, or at most 1 day of work for the worst paid jobs. And it will run for years, and do routine tasks up to thousands of times faster than any employee. With that, the only excuse that people still do routine tasks, is the inaccessibility of coder time.
Solution: everybody should know how to write code, even at the simplest level.
Blue-collar jobs: they will be obsolete. Many of them already are. The rest are waiting for their turn.
Marketing people - marketing is online. They need to know how to set up proper tracking in JS, how to get atomic data in some form of SQL, how to script some automated adjustments via APIs for ad budgets, etc. Right now they're asking for developers to do that. If they learn to do that, they'll be an independent, valued asset. Employers WILL ask for this as a bonus.
Project Managers - to manage developers, they need to know what they do. They need to know code, they have to know their way around repositories.
QA staff - scripted tests are the best, most efficient tests.
Finance - dropping Excel in favor of R with Markdown, Jupyter Notebooks or whatever, is much more efficient. Customizing / integrating their ERP with external systems is also something they could do if they knew how to code.
Operations / Category Management - most of it would go obsolete with more companies adopting APIs as a way to exchange important information, rather than phone calls and e-mails.
Who would not be replaced or who wouldn't benefit from programming? Innovative artists.
A lot of it might not be now now, but the current generation will see it already in their career.
If we educate people today, without advanced computer skills and some coding, then we are educating future deadbeats.
With all this, all education should include CS. And not just as a mandatory field or something. Make it more accessible, more interesting, more superficial if needed. Go straight to use cases, show its effectiveness in the easiest way possible. Inquisitive minds will fill in the blanks, and everyone else will at least know how to automate a part of their work.
Soooo I am an apprentice who just started his third year. Everybody in my team (3 ppl) left for better jobs.
I am now basically front and backend lead, teaching four new employees our restapi, web and javafx frontend.
At the same time I fix errors happening in production and develop new features.
I guess there are many great rants to come, so stay tuned :D
Going to write about things like tests that got disabled months ago after migrating to gradle, no documentation, finding out how to set up new development workstations with an outdated script missing important steps, management, print debugging in production and much more :)
Oh and it is not that bad, I learned more in the last month than in the two years before. (not saying my team was bad)1
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!
[Update on previous rant at the bottom]
So I had the technical test last friday. I did not try to implement any automated test as it is not my forte.
I had three hours to showcase my knowledge of data structures and OOP so I did that.
The test was somewhat long actually, so I left out one part that I did not have time to implement: validation of input files.
Today I got feedback, everything went well, they liked my code and I only got two negatives: Error handling and automated tests xD
Now I'm going to the second phase: phone interviews and they are gonna asks the whys of my implementation.
I'll have to explain why I did not implement automated tests and the girl on the phone told me "they didn't like it much that you had no tests because tests are very important for us".
I guess I'll have to come clean and say that I'm not very strong on that but willing to learn, so I didn't want to risk it doing something I'm not really good at.
I hope it ends up well.
first some background. I'm an intern coming in on the end of my internship (tomorrow's my last day). I've been working on a reasonably important project, more specifically a restful API. We have automation set up so that any commits to master on GitHub are pushed out into a live, accessible version. Some guy (let's call him dumbass) joined our team last week, and has had a few ideas
Dumbass: *opens pull request to my repo*
My boss: *requests changes*
Me: *requests different changes*
(All this before even testing his code, mind you)
Dumbass: *makes requested changes*
Me: *approves changes*
A day passes
My boss: *approves changes*
Me (not even 10 seconds after my boss approved changes): *requests more changes*
(Still haven't tested his code, I just ran A PEP8 compliance test)
Dumbass: *MERGES CHANGES TO MASTER*
Literally EVERYTHING breaks because he was importing a module that's not available
We don't notice until later that day (I'm still working on writing the tests for the automation, for now changes get put on live version even if everything breaks -- tool is still in beta, so everyone working on it (a whole 3 people) knows to TEST THEIR SHIT BEFORE MERGING TO MASTER.)
WHY EVEN BOTHER WITH THE PULL REQUEST IF YOU WERE GOING TO MERGE TO MASTER YOURSELF ANYWAY??!??!??
My frustration cannot be properly conveyed through text, but let's just say this guy's been there a week, I already didn't like him, and then he fucking does this.
Risk is part of my everyday life.
I take the risk everyday when opening IDE and changing line of code that can either break database or crash other systems that are depending on one I am developing. ( not instantly but in some time in the future )
Many years ago I was updating some application server production code while being drunk.
Everything went fine except me waking up in the morning and didn’t remember how I did it.
... what I learned from my developers life except that heavy drinking and updating servers is not the best idea ?
First, don’t give a fuck, do your job and ask questions even if the person in front of you said that understood everything and you think you understood all of shit.
Second, if you think you know what to do think twice.
Third, having any backup, any tests and any documentation is always better then having nothing.
And the most important.
The most risky in every business are people around you, so always have good people around and there would be no risk at all or you won’t even think about it.
And here it comes bois, the famous Monday Morning Mumbling is back, for everyone's pleasure.
Do you remember your uni years, when you had wonderful coding lessons, and you learned sick languages ?
I do aswell, since I'm still in uni.
But why, WHY, IN ALL OF GOD THOUGHTS, DO I STILL HAVE TO TAKE MATHS LESSONS ?
It's my fourth fucking uni year, and I'm still supposed to deal with math lessons which are about what I learned 6 years ago. And guess what ? I still failed the test since I fucking don't understand a single shit in maths.
"Uuuuh if yu wan tu derivate a function u hav to multiply ur derivated function basic expression with the derivate itself lul xDDD so funi"
FUCK OFF DUDES I DON'T GIVE A SINGLE SICK BIRD SHIT ABOUT MATHS. I WASTED THREE YEARS OF MY LIFE LEARNING ABOUT BINARY TREES, MATHEMATICALS WAYS OF SPILLING YOUR CEREAL BOWL WHEN YOU HAVE TO LEAVE IN FIVE MINUTES, NUMERIC WAY OF OPTIMIZE YOUR SINK SPACE WHEN YOU'RE TOO LAZY TO DO THE DISHES, JUST LET ME FUCKING WRITE CODE INSTEAD OF ANNOYING ME WITH UNEXPLAINABLE MATHS SHIT NOW !
I know maths are important, okay ? But I'm so fucking tired of learning this shit again and again and still failing those shitty tests where they only give you maths problems without any other goal than messing with your grades.
Fuck this shit I'm pissed off on so many levels, I wasted tons of money on a private school to enhance my résumé history, and now I'm stuck with some strange "f'(x)" boi that will ruin my year.
RT's appreciated, if you recognised yourself in this story, don't forget to send some biscuits to my postal address.
TL;DR : Why wasting your time on theoritical lessons when you could use your time to learn new dynamic technos, like C++98 ?2
I want to ask for your opinion guys, because I don't know if I am right or wrong.
So, some days ago, my brother sent me some code to check out for an automation that he does for testing purposes, since he's a QA (I am a programmer). He should be able to send XML data to a server and depending on the process that he tests, the data is different every time. I saw a strange thing, he hardcodes the XML tags and concatenates them with data which I find stupid. So I proposed him to use a template to generate XML data, because I think it's more flexible and easier, making data and presentation separate. That way if in the future he wants to start using JSON he could do it in no time. I made the code in a separate file which he imports and uses it's functions (they are two so no need for classes) and uses them to load the template and render it as he passes the data as a hash table. He insists that concatenating data and XML tags is easier and simpler and I can't wrap my mind how could that be true. I gave him an example in which the data structure for a process is changed and he have to open the file and change the XML tags or the structure and he still says that's simpler.
What is the right decision in this situation. Keep in mind that I simplified the process a lot and it actually involves sending the data and reporting the results, but they are not important here since I am talking only about generating data.