Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "but not really they're cool sometimes"
-
I might have posted this before. But I am going to post it again. Because emojis.
Me: 😁 Software lead I have finished coding the thing.
SL: 😀 Cool, good job. That is going to really help out the analysts.
Software Manager: 😐 hey I noticed you have coded a new thing and pushed it to integration.
Me: 😁 Yes.
SM: 😐 Well how do you know when it's done?
Me: 😑 . . . When you run it and it does the thing?
SM: 😐 Did you write test steps?
Me: 😕 Yeah . . . they're in the issue ticket.
SM: 😐 Yeah but how do you know those are right?
Me: 😕 Because I wrote the thing and the test steps?
SM: 😐 did you put any steps in our acceptance test procedure?
Me: 😕 No.
SM: 😐 why not?
Me: 😧 Because the acceptance test procedure tests requirements. There is no requirement for this functionality.
SM: 😑 Then why did you do it?
Me: 🤔 Because it was an internal request from the analysis team. There is no customer impact here.
SM: 😑 I really think we should write a requirement.
SL: 🤔 But what requirement is he going to attach this to?
SM: 😑 We don't have to attach it to a requirement. We can just test it once and remove it.
Me: 😒 SM, you know we never remove anything from the acceptance test procedure.
SM: 🙂 We do sometimes.
SL: 🤔 When was that I have worked here for twenty years and we have never removed a test from that document.
SM: 😑
SL: 😒
SM: 😑
SL: 😒
Me: 🤐
SM: 😧 I really think there should be an acceptance test written.
SL: 😧 Looks like you're writing an acceptance test.
Me: 😒 Alright as long as y'all're payin'. Shit I was just tryin' to save y'all money.
*acceptance test written and sent to peer review*
Peer: 😐 The requirement tested section doesn't have any requirements spelled out.
Me: 😅 No.
Peer: 🤔 Why?
Me: 😓 Because there is no requirement associated with this test.
Peer: 🤔 Then why are we adding an acceptance test?
Me: 😡 WELL AIN'T THAT A GOOD GOD DAMN QUESTION!?6 -
Disclaimer: Long tale of a tech support job. Also the wk29 story is at the bottom.
One time I was working tech support for a website and email hosting firm that was in town. I was hired and worked as the only tech support person there, so all calls came in through me. This also meant that if I was on a call, and another one came through, they would go straight to voice mail. But I couldn't hang up calls either, so, sometimes someone would take up tons of time and I'd have to help them. I was also the "SEO" and "Social Media Marketing" person, as well; managed peoples' social media campaigns. I have tons of stories from this place but a few in particular stick out to me. No particular order to these, I'm just reminiscing as I write this.
I once had to help a man who couldn't find the start button on his computer. When I eventually guided him to allowing me to remote into his computer via Team Viewer, I found he was using Windows XP. I'm not kidding.
I once had to sit on the phone with a man selling Plexus Easy Weight Loss (snake oil, pyramid scheme, but he was a client) and have him yell at me about not getting him more business, simply because we'd built his website. No, I'D not built his website, but his website was fine and it wasn't our job to get him more business. Oh yeah, this is the same guy who said that he didn't want the social media marketing package because he "had people to hide from." Christ.
We had another client who was a conspiracy theorist and wanted the social media marketing package for his blog, all about United States conspiracies. Real nut case. But the best client I've ever had because sometimes he'd come into the office and take up my time talking at me about how Fukushima was the next 911 and that soon it'll spill into the US water supply and everybody was going to die. Hell, better than being on the phone! Doing his social media was great because he wanted me to post clearly fake news stories to his twitter and facebook for him, and I got to look at and manage all the comments calling him out on his bullshit. It was kinda fun. After all, it wasn't _me_ that believed all this. It felt like I was trolling.
[wk29] I was the social media and support techie, not a salesperson. But sometimes I was put in charge _alone_ in front of clients for status meetings about their social media. This one time we had a client who was a custom fashion-type person. I don't really remember. But I was told directly to make them a _new_ facebook page and post to it every day with their hot new deals and stuff. MONTHS pass since I do that and they come in for a face-to-face meeting. Boss is out doing... boss things and that means I have to sit in with her, and for some fucking reason she brought her boyfriend AND HER DAD. Who were both clearly very very angry with me, the company, and probably life. They didn't ever say anything at first, they didn't greet me, they were both just there like British royal guards. It was weird as fuck. I start showing them the page, the progress on their likes goals, etc etc. Marketing shit. They say, "huh, we didn't see any of these posts at home." Turns out they already had a Facebook page, I was working on a completely seperate one, and then the boyfriend finally chimes in with the biggest fucking scowl, "what are you going to do about this?" He was sort of justified, considering this was a payed and semi-expensive service we offered, but holy shit the amount of fire in all three of them. Anyway, it came down to me figuring out how to merge facebook pages, but they eventually left as clients. Is this my fuck up? Is it my company's? Is it theirs? I don't know but that was probably the most awkward meeting ever. Don't know if it comes across through text but the anxiety was pretty real. Fuck.
tl;dr Tech support jobs are a really fun and exciting entry level position I recommend everybody apply for if they're starting out in the tech world! You'll meet tons of cool people and every day is like a new adventure.2 -
Github 101 (many of these things pertain to other places, but Github is what I'll focus on)
- Even the best still get their shit closed - PRs, issues, whatever. It's a part of the process; learn from it and move on.
- Not every maintainer is nice. Not every maintainer wants X feature. Not every maintainer will give you the time of day. You will never change this, so don't take it personally.
- Asking questions is okay. The trackers aren't just for bug reports/feature requests/PRs. Some maintainers will point you toward StackOverflow but that's usually code for "I don't have time to help you", not "you did something wrong".
- If you open an issue (or ask a question) and it receives a response and then it's closed, don't be upset - that's just how that works. An open issue means something actionable can still happen. If your question has been answered or issue has been resolved, the issue being closed helps maintainers keep things un-cluttered. It's not a middle finger to the face.
- Further, on especially noisy or popular repositories, locking the issue might happen when it's closed. Again, while it might feel like it, it's not a middle finger. It just prevents certain types of wrongdoing from the less... courteous or common-sense-having users.
- Never assume anything about who you're talking to, ever. Even recently, I made this mistake when correcting someone about calling what I thought was "powerpc" just "power". I told them "hey, it's called powerpc by the way" and they (kindly) let me know it's "power" and why, and also that they're on the Power team. Needless to say, they had the authority in that situation. Some people aren't as nice, but the best way to avoid heated discussion is....
- ... don't assume malice. Often I've come across what I perceived to be a rude or pushy comment. Sometimes, it feels as though the person is demanding something. As a native English speaker, I naturally tried to read between the lines as English speakers love to tuck away hidden meanings and emotions into finely crafted sentences. However, in many cases, it turns out that the other person didn't speak English well enough at all and that the easiest and most accurate way for them to convey something was bluntly and directly in English (since, of course, that's the easiest way). Cultures differ, priorities differ, patience tolerances differ. We're all people after all - so don't assume someone is being mean or is trying to start a fight. Insinuating such might actually make things worse.
- Please, PLEASE, search issues first before you open a new one. Explaining why one of my packages will not be re-written as an ESM module is almost muscle memory at this point.
- If you put in the effort, so will I (as a maintainer). Oftentimes, when you're opening an issue on a repository, the owner hasn't looked at the code in a while. If you give them a lot of hints as to how to solve a problem or answer your question, you're going to make them super, duper happy. Provide stack traces, reproduction cases, links to the source code - even open a PR if you can. I can respond to issues and approve PRs from anywhere, but can't always investigate an issue on a computer as readily. This is especially true when filing bugs - if you don't help me solve it, it simply won't be solved.
- [warning: controversial] Emojis dillute your content. It's not often I see it, but sometimes I see someone use emojis every few words to "accent" the word before it. It's annoying, counterproductive, and makes you look like an idiot. It also makes me want to help you way less.
- Github's code search is awful. If you're really looking for something, clone (--depth=1) the repository into /tmp or something and [rip]grep it yourself. Believe me, it will save you time looking for things that clearly exist but don't show up in the search results (or is buried behind an ocean of test files).
- Thanking a maintainer goes a very long way in making connections, especially when you're interacting somewhat heavily with a repository. It almost never happens and having talked with several very famous OSSers about this in the past it really makes our week when it happens. If you ever feel as though you're being noisy or anxious about interacting with a repository, remember that ending your comment with a quick "btw thanks for a cool repo, it's really helpful" always sets things off on a Good Note.
- If you open an issue or a PR, don't close it if it doesn't receive attention. It's really annoying, causes ambiguity in licensing, and doesn't solve anything. It also makes you look overdramatic. OSS is by and large supported by peoples' free time. Life gets in the way a LOT, especially right now, so it's not unusual for an issue (or even a PR) to go untouched for a few weeks, months, or (in some cases) a year or so. If it's urgent, fork :)
I'll leave it at that. I hear about a lot of people too anxious to contribute or interact on Github, but it really isn't so bad!4 -
When the CTO/CEO of your "startup" is always AFK and it takes weeks to get anything approved by them (or even secure a meeting with them) and they have almost-exclusive access to production and the admin account for all third party services.
Want to create a new messaging channel? Too bad! What about a new repository for that cool idea you had, or that new microservice you're expected to build. Expect to be blocked for at least a week.
When they also hold themselves solely responsible for security and operations, they've built their own proprietary framework that handles all the authentication, database models and microservice communications.
Speaking of which, there's more than six microservices per developer!
Oh there's a bug or limitation in the framework? Too bad. It's a black box that nobody else in the company can touch. Good luck with the two week lead time on getting anything changed there. Oh and there's no dedicated issue tracker. Have you heard of email?
When the systems and processes in place were designed for "consistency" and "scalability" in mind you can be certain that everything is consistently broken at scale. Each microservice offers:
1. Anemic & non-idempotent CRUD APIs (Can't believe it's not a Database Table™) because the consumer should do all the work.
2. Race Conditions, because transactions are "not portable" (but not to worry, all the code is written as if it were running single threaded on a single machine).
3. Fault Intolerance, just a single failure in a chain of layered microservice calls will leave the requested operation in a partially applied and corrupted state. Ger ready for manual intervention.
4. Completely Redundant Documentation, our web documentation is automatically generated and is always of the form //[FieldName] of the [ObjectName].
5. Happy Path Support, only the intended use cases and fields work, we added a bunch of others because YouAreGoingToNeedIt™ but it won't work when you do need it. The only record of this happy path is the code itself.
Consider this, you're been building a new microservice, you've carefully followed all the unwritten highly specific technical implementation standards enforced by the CTO/CEO (that your aware of). You've decided to write some unit tests, well um.. didn't you know? There's nothing scalable and consistent about running the system locally! That's not built-in to the framework. So just use curl to test your service whilst it is deployed or connected to the development environment. Then you can open a PR and once it has been approved it will be included in the next full deployment (at least a week later).
Most new 'services' feel like the are about one to five days of writing straightforward code followed by weeks to months of integration hell, testing and blocked dependencies.
When confronted/advised about these issues the response from the CTO/CEO
varies:
(A) "yes but it's an edge case, the cloud is highly available and reliable, our software doesn't crash frequently".
(B) "yes, that's why I'm thinking about adding [idempotency] to the framework to address that when I'm not so busy" two weeks go by...
(C) "yes, but we are still doing better than all of our competitors".
(D) "oh, but you can just [highly specific sequence of undocumented steps, that probably won't work when you try it].
(E) "yes, let's setup a meeting to go through this in more detail" *doesn't show up to the meeting*.
(F) "oh, but our customers are really happy with our level of [Documentation]".
Sometimes it can feel like a bit of a cult, as all of the project managers (and some of the developers) see the CTO/CEO as a sort of 'programming god' because they are never blocked on anything they work on, they're able to bypass all the limitations and obstacles they've placed in front of the 'ordinary' developers.
There's been several instances where the CTO/CEO will suddenly make widespread changes to the codebase (to enforce some 'standard') without having to go through the same review process as everybody else, these changes will usually break something like the automatic build process or something in the dev environment and its up to the developers to pick up the pieces. I think developers find it intimidating to identify issues in the CTO/CEO's code because it's implicitly defined due to their status as the "gold standard".
It's certainly frustrating but I hope this story serves as a bit of a foil to those who wish they had a more technical CTO/CEO in their organisation. Does anybody else have a similar experience or is this situation an absolute one of a kind?2