Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuckBuy Now
Search - "what teamwork"
So lot of people ask me here what is Testing?
Well, I have decided to post about it instead of answering every request individually as it is tiresome. So here we go...
- Why to test?
Testing is breaking down a piece of code so that all the possible logical and functional errors can be detected while in development phase, so that the disaster can be prevented in production.
- How to test a piece of code/software?
There are various types of testing like unit, sanity/smoke, functional, regression, performance, security, penetration to name a few. Each has it's own significance and to know more you can Google/DDG them.
- What to test?
We can test any and everything. You can test code, UI, UX, speed of application, database flow, logical flow, functional flow, et cetera.
Testing is an attitude, not a skill. Cannot be taught but only developed by one ownself.
To be good at testing, one needs to have a good design and business sense, apart from technical and functional knowledge.
Many will say, to test one needs to think outside the box. Fuck that. There is no box. Everything is a sandbox and do whatever the fuck you want to, to break things.
Most importantly, thinking from other person's perspective is critical as this helps you think what can an user do with your software. Trust me, humans are idiots and can literally fuck your software doggy style and make you wonder why your code isn't working?
To build an idiot proof software, we need to think beyond human levels.
Never think the obvious. NEVER.
Always try what you think can never happen. System will break, I promise.
Finding loopholes is way easier than you think. Fixing them is surely a challenge.
Moreover, to survive in corporate world leaning the processes is important. The SDLC cycle is what makes a software great.
And today I realised that no role is stupid. Testing is looked down upon in my country. Possibly, IT is the only field where testing has least value as compared to other places like food testing or automobile crash testing et cetera.
And I, myself used to think support is a stupid job requiring no skills. But today I talked to a friend in support and realised that they have more technical skills than a tester.
Everyone is important and we shouldn't look down upon any person or role. Nobody is superior, nobody is inferior. We all are equal.
Together we shall work as a team and a great teamwork can achieve wonders.
Hope this helps. Thak you for reading and do provide your feedback as it shall help me improve.
P.S.: last week somebody tagged me to a new comer's post seeking advice for testing. I don't recollect that so please tag them here again. Thanks.
Edit: I feel like and I might have, missed out some points so please excuse me for that.21
TLDR someone in my team took credit for work he didnt do;
I know teamwork is a good thing and when everyone does their share of the work, it is.
I submitted a computer science project to an event in the UK called the Big Bang fair, I was in a group of 3. We had been meeting every week after for the past 10 months. During these sessions me and uke have been meeting for 1h 30m where as oon could only meet for 1h because "he had stuff to do" and he never saw the point in staying longer. Oon had also been a massive distraction whilst the time he was there as he did no work and messed around on cookie clicker.
Anyway we found out last week that the Big Bang fair was coming very soon and we had not written a write up or done any preparation for the presentation we had to do. Me and uke set up a google doc and started adding stuff to it (as we only had a few days left at this point). Whereas oon did nothing.
I ended up staying up till 3am in the morning finalising the write up over the weekend with uke helping. We asked oon to help but he said he didnt want to stay up late so didnt help.
Then the most stressful 2 days come round. I devoted all of my free time towards the project, uke devoted most of his time and oon devoted 1 hour after school on one day. He said that he couldn't do one lunchtime but I found him in the ICT room playing games :/.
This didn't matter THAT much but what pissed me off is that he started boasting to all his friends about all the work I did and credited it as his own. At the actual event he said nothing during the presentation because he knew nothing about the project. HE DIDNT EITHER BOTHER TO READ THE WRITE UP HE WAS BOASTING ABOUT. What do people get out of taking credit for work other people did.
We didn't win anything and I wonder why
wow thanks for reading all this you deserve a sticker1
!rant && !!rant
☝️ What does that give you?
Today will be the last day we gonna work at this fucking hellhole of an office. Since I had so many shits to remember from this office, let me share my favorite.
1) Ground floor. Got flooded last July. Half our equipments got soaked. Oh equipments as in computers, cables, reports documents, etc etc.
2) I am gonna miss those connection down days.
3) I will also miss those black out days where we couldn't work for hours so had to play teamwork games to keep the morale of the team and you know to stay awake.
4) I will also miss that fucking mouse or rat. You are small and cute but fuck you for chewing my potato chips and peanuts. A-hole.
5) No windows so with no air-conditioning, it is a literal hell hole.
Gotta stop. I might cry.17
Two years ago, I developed an security app for Android as a school project. I didn't like teamwork at school (you know, you do all the work and everyone else is getting the same grade you receive, specially if you are the nerd of the class), actually I hated it, so I made it alone.
Its name was "Alex" and was a simple "panic button". You can configure two emergency emails and phone numbers (contacts only, not police) and, if you're in danger, you just have to press the button and the app is gonna send two messages/emails to your contacts: the first one, to tell where are you (GPS, only the name of the place) and that you're in problems. The second one with an audio/photo file of the situation.
Sounds like a great app, and I tested it few times. The reason I didn't continue with this is that I got my first job and I had not time, and that, tree or four months later, the government (of the city) launched a similar app. Less sophisticated, but I think it's still useful: "No estoy sola"(I'm not alone). I haven't tested it cause I don't trust on the authorities, I'd preffer to send my location to a friend through messenger app instead.
I don't know if I should re-work this app (I didn't released it, I just have the beta) or work on something else. I'm afraid that, if I release it, someone could die or get kidnapped because of a bug or something going wrong with the app :c What do you think?5
> Worst work culture you've experienced?
It's a tie between my first to employers.
First: A career's dead end.
Bosses hardly ever said the truth, suger-coated everything and told you just about anything to get what they wanted. E.g. a coworker of mine was sent on a business trip to another company. They had told him this is his big chance! He'd attend a project kick-off meeting, maybe become its lead permanently. When he got there, the other company was like "So you're the temporary first-level supporter? Great! Here's your headset".
And well, devs were worth nothing anyway. For every dev there were 2-3 "consultants" that wrote detailed specifications, including SQL statements and pseudocode. The dev's job was just to translate that to working code. Except for the two highest senior devs, who had perfect job security. They had cooked up a custom Ant-based build system, had forked several high-profile Java projects (e.g. Hibernate) and their code was purposely cryptic and convoluted.
You had no chance to make changes to their projects without involuntarily breaking half of it. And then you'd have to beg for a bit of their time. And doing something they didn't like? Forget it. After I suggested to introduce automated testing I was treated like a heretic. Well of course, that would have threatened their job security. Even managers had no power against them. If these two would quit half a dozen projects would simply be dead.
And finally, the pecking order. Juniors, like me back then, didn't get taught shit. We were just there for the work the seniors didn't want to do. When one of the senior devs had implemented a patch on the master branch, it was the junior's job to apply it to the other branches.
Second: A massive sweatshop, almost like a real-life caricature.
It was a big corporation. Managers acted like kings, always taking the best for themselves while leaving crumbs for the plebs (=devs, operators, etc). They had the spacious single offices, we had the open plan (so awesome for communication and teamwork! synergy effects!). When they got bored, they left meetings just like that. We... well don't even think about being late.
And of course most managers followed the "kiss up, kick down" principle. Boy, was I getting kicked because I dared to question a decision of my boss. He made my life so hard I got sick for a month, being close to burnout. The best part? I gave notice a month later, and _he_still_was_surprised_!
Plebs weren't allowed anything below perfection, bosses on the other hand... so, I got yelled at by some manager. Twice. For essentially nothing, things just bruised his fragile ego. My bosses response? "Oh he's just human". No, the plebs was expected to obey the powers that be. Something you didn't like? That just means your attitude needs adjustment. Like with the open plan offices: I criticized the noise and distraction. Well that's just my _opinion_, right? Anyone else is happily enjoying it! Why can't I just be like the others? And most people really had given up, working like on a production line.
The company itself, while big, was a big ball of small, isolated groups, sticking together by office politics. In your software you'd need to call a service made by a different team, sooner or later. Not documented, noone was ever willing to help. To actually get help, you needed to get your boss to talk to their boss. Then you'd have a chance at all.
Oh, and the red tape. Say you needed a simple cable. You know, like those for $2 on Amazon. You'd open a support ticket and a week later everyone involved had signed it off. Probably. Like your boss, the support's boss, the internal IT services' boss, and maybe some other poor sap who felt important. Or maybe not, because the justification for needing that cable wasn't specific enough. I mean, just imagine the potential damage if our employees owned a cable they shouldn't!
You know, after these two employers I actually needed therapy. Looking back now, hooooly shit... that's why I can't repeat often enough that we devs put up with way too much bullshit.3
IF YOU UPDATE AN ADM PLATTFORM FOR FUCKS SAKE DON'T DO THE FOLLOWING THINGS:
1. ONLY DOCUMENTATE IT IN A POWERPOINT
2. WRITE DOWN IPs AND PORTS ONLY ON A WHITE-BORD
3. MOVE TOOLS TO OTHER SUBNETS OR DOMAINS WITHOUT PROPERLY KNOWING THE WAYS OF COMMUNICATION BETWEEN THEM
4. USE YOUR PERSONAL EMAIL ADDRESS AS RESET OPTION FOR LICENCE-MANAGEMENT ACCESS IF NO ONE KNOWS THE PW
5. LEAVE THE COMPANY THE DAY AFTER THE UPGRADE IS DONE
Because the guy who has to take care of the upcoming problems is not going to like you!
BUT having to deal with all of this at once would not be a problem if your, so called team (30 People who work with those applications e.g. as test-engineers) would actually work together instead of having that "not my daily business, I am going to drink coffee" attitude.
Apparently I am the only one who has enough balls to see, admit, and report a problem to our leadership.
This always leads to Me fixing the issue...
....that's alright I am learning a lot...
...BUT IF A TEAM-MATE, WHO HAS THE SAME DEGREE AS I AM GOING TO GET, LEAVES EARY BECAUSE: "HE DOES NOT KNOW WHATS WRONG", IT TRIGGERS ME!!!
- The apprenticeship guy
PS Needless to say hundreds of clients have access to those systems and I worked through a shittload of official tool docs just to get to know the tools first...6
Mentors, take note. This is a best practice over here.
I've spent two days digging through obscure documentation trying to accomplish one of those tasks that is simple in word and complex in deed. Namely, I wanted to concatenate (not delete) near-duplicate values in Pandas before rendering the data into a graph. Two days beating my head against the wall.
One of my mentors (I'm an intern) heard about the issue, wrote in the proper line (a very specifically and archaically formatted command), and pushed it to repo without even asking for thanks. Works like a charm and he saved my rear end. What a guy.
Please, mentors, don't leave your interns hanging on problems where the only solution is shrouded in dubious documentation and magic syntax. Especially when there's a deadline involved. Let them struggle on logic flow and writing good code.
Be like this guy. You'll build the importance of teamwork and your intern will think you're a wizard.2
Biggest teamwork fail? This is the general way we do business where I work right now:
My boss didn’t want to be the kind who hovers, always micromanaging. He also hates the idea of taking programmers away from their work for meetings. Sounds great, right? This has resulted in:
• All non-lead devs being excluded from all meetings other than scrum (including sprint planning and review meetings). Nobody ever knows what the hell is going on. They don’t think we “need to know.” This means most of our day is spent trying to figure out what needs to be done, rather than getting anything done.
• Our remote boss making dozens of important decisions about our platform, never telling us, and blaming us for not forcing our lead to be more communicative.
• Pull requests staying open for weeks, sometimes months, because nobody has definitively decided what version we’re actually supposed to be working on. This means our base branch could be any of them, and it means PRs that have been opened too long need to be closed, updated, and re-opened on the false promise of someone actually looking at it.
Just ranting here... but I think our biggest teamwork fail is happening right now, with all of those things ^4
We need more positivity:
Reason why you like coding? / Reason why you chose it as your career? / Why wouldn't you want to do something different?
Best feeling when coding
Nicest colleague/Best teamwork experience/Best boss/easiest client
What do you like about your position/job/company
Besides coding, what makes you happy
Your favorite stack/language/working environment3
Oh where to start.
TLDR, *actually* prepare students for the *real world*.
- TEACH GIT.
- Stop with the useless projects with esoteric restrictions that absolutely do not exist in the software work field
- ENCOURAGE collaboration rather than make it academic dishonesty with high punishment consequences. Devs need to learn Teamwork!!
- Don't start 101 with Python then go straight to C++ in 102
good lord, the easier question is what DOESN'T need to change in CS undergrad programs.
My collaborator was always telling me what a great team we are, until it got serious.
Getting stabbed back in the butt and fired from your job. HAHA what great Teamwork...
After that steal all my ideas and projects and sell them as there own.
I hope that guys Flip-Flops will burn someday1
My GOTOs are:
- Check if focus on teamwork is emphasized. Does the company state themselves? Spend a day with the team if possible, see how they work together.
- What tools do they use? Sometimes this will hint you towards whether or not you will encounter a good environment or a jumbled mess.
- Is there organized communication? I know, sometimes there are too many meetings, but that is better than too vew. How often does the team meet, even if just for 10mins? How does management communicate with the team? What ways are provided to give feedback? Are suggestions to improve practices welcome?
I left my last company and joined my current one, where these things work out the way they should. While I liked both projects with respect to development, my mental state has improved dramatically in the new environment. Stress is down, productivity is up. I love my job.
Sometimes we woulg get a request which involves adding something or changing something to a rather large and poorly made codebase which me and my lead have not had the time to change.
This b how shit goes:
* the lead gets a call after an email was sent with apparently only 5 secs of response time( inpatient fucks)
* lead calls me in next to his station to listen to the call
* i b listening and shit, not even taking notes and shit, looking all secret weapon and shit.
Texas as fuck.
* lead puts shit on hold and looks at me
Lead: "Allright. You know the codebase as well as I do, what you think?"
Me: pffft gimme 30 mins and Ill whip out yo solution
Lead: we positive on the estimate?
Me: as positive as the Texas Rangers sucking ass but we still love em, fuck the Astros
Lead: there is only room for one team
Me: only one
* goes back to the call:
Lead: yeah its gonna take 2 days at most.
Aaaaaaaaaaaaaaand we do finish them in 30 mins. The trick is in doing it extra fast so we have enough time to fuck around or do some other shit and to make it seem like we do some hard shit. After maybe 6 hours we tell them that we managed to fix it before time.
Btw me and the lead tall about whatever while we code the stuff, most of the time I do it since my boy has heavy eye problems and I want him to relax. He has been training me a lot in regards to knowing the codebase, before I got here it was only him for two fucking campuses and the man did an outstanding job. My boy got my ass and I got his.
Teamwork, the southern gentleman's way.
P.d while coding it he said the one of the file sizes was too big to handle, i said "das what she said" and our female manager said "i heard that".......i could have sworn that she gave me a lil wink. Well damn.8
If you are a developer and you are proud of the work you contribute whilst remaining open minded, I applaud you. If you are a developer and you are overly proud of what you do, and you believe the work you contribute to a software project caries more value than the work another developer contributes, then go fuck yourself.
I am sick and tired of working on teams with people who are self-righteous. What you bring to the table is important, but it isn't the only thing brought to the table, so stop acting like what you brought to the table is the best thing on the fucking table.
What makes it worse is when someone disagrees with your work and you aren't willing to take any of it. You deny their opinion as if yours is vastly superior. YOU need to improve your teamwork skills, YOU need to stop being so arrogant and self-righteous, YOU are the problem.2
Honestly? In a way. The degree itself did not bring me anything more that I already had. The process, on the other hand, was very useful. Both medicine and SW engg. courses taught me a lot: patience, manipulation, listen carefuly to what is asked/told [rather than assuming I know it all], dealing with consequences of my decisions, teamwork, "I must", "I mustn't", "I will", etc.
As for tech skills - nay, I didn't get anything new from IT course [although I've learned a freaking lot in med].
In our class we have one subject where we take notes on one shared Google docs document. To be honest, this may be the worst "teamwork" that I every had to deal with.
• Simply copying the stuff from the blackboard:
• Missing context
• document consists of keywords and occasional sentences
• These fucking deep nested lists
• No quality control whatsoever
--> nobody fucking cares
• What, nobody made notes for this point?
• Any attempt to speak up result in me being scolded
• Be me, the only one not shopping on amazon instead of taking notes
• Wtf does this mean, where's the context
• one line of code without needed context code
No quality, no Motivation, no better alternatives, no fun.
Worst part of being a dev?
When you need to work together with people that are too stubborn. Recently I needed to work together with 2 guys and when they started ranting on me for literally nothing, I realized not everyone is able to work in a team.
Now im ranting back on them.
What are your experiences with people like this and what do you do to make teamwork more enjoyable?
What non-technical qualities does a software engineer need to be successful?... Attitude? Communication skills? Vision? Teamwork? Passion?... What do you think? And why?9