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 - "agile in practice"
-
Fuck. My new job in the public sector requires me to sign paper applications to access JIRA or git. It takes them 4 days to process, so now I am waiting at home doing nothing. I’ll still get paid a competitive developer salary, though.
If you are a EU citizen from a country that subsidizes Poland, you can be sure that your taxes are well spent on my couch :)9 -
Agile in practice.
I finished my story with 3 days left in our 2 week sprint.
Me: What story should I pull in next?
PM: Story <number> to add <new feature>
Me: ok, sounds good
PM: Will you finish it before our sprint ends?
Me: No, probably will take me 5-7 days.
PM: But it can't spill over, it will make our metrics look bad.
Me: I can't finish it in 3 days.
PM: ....
Me: Can't you just explain the spillover as us working ahead?
PM: It will look bad on our <automated-report>
Me: ....
Me: So don't want me to get started on <new feature>?
PM: ....
Me: <internally sighing> What do you want me to do?
PM: Maybe you can pair program with <Overpaid-Idiot-Programmer> to help finish their story
Me: ....
Me: feelsbadman.jpg14 -
What are your thoughts on working for a company that give their devs jira tickets that don't have any descriptions? I work for a big organisation (It's actually in the top 3 biggest companies in the country I live in) and I work in a team that has quite possibly the worst agile practice I've ever seen. We get tickets without any descriptions at all. The worst bit is then we get pressure from project management for not delivering things on time. Do they actually realise how difficult it is to deliver something without any business requirements? I have to have a million meetings before I even know wtf the ticket is about. It's incredibly annoying.13
-
What do you tell interviewers as a "Senior developer" when they ask you what you do at your current job.
I've been with my current for almost 8 years, since graduating... Few different time but not very well managed (semi/barely agile). Hasn't really provided any skill growth opportunities. Mostly fixing production issues, chasing other teams.
The projects I've worked on are in many different languages either enhancements or some standalone stuff. But nothing that's huge and I don't think I've learned anything from them. I usually apply what I learn and practice outside of work to work.
So to me I can probably list a whole lot of projects but to me their not that amazing, I didn't learn anything from them.
Also about those algorithm questions. I've never used any of this stuff actually at work. Concepts yes but not how do you implement ... And honestly I've never once had a situation that required algorithmic thinking other than maybe writing recursive functions in rare occasions...
But to me I've never once done anything harder or new which I haven't already done on my own....
Sorry for the disorderly rambling this turned into... which is sorta a problem too.
Everytime I think about interviews, I want to give rants about we technical questions are BS, how I probably have enough real experience to tackle any problem and come up with a good plan/solution (in a realistic timeframe, not 20 minutes from design to implementation)2 -
Some of you know I'm an amateur programmer (ok, you all do). But recently I decided I'm gonna go for a career in it.
I thought projects to demo what I know were important, but everything I've seen so far says otherwise. Seems like the most important thing to hiring managers is knowing how to solve small, arbitrary problems. Specifics can be learned and a lot of 'requirements' are actually optional to scare off wannabes and tryhards looking for a sweet paycheck.
So I've gone back, dusted off all the areas where I'm rusty (curse you regex!), and am relearning, properly. Flash cards and all. Getting the essentials committed to memory, instead of fumbling through, and having to look at docs every five minutes to remember how to do something because I switch languages, frameworks, and tooling so often. Really committing toward one set of technologies and drilling the fundamentals.
Would you say this is the correct approach to gaining a position in 2020, for a junior dev?
I know for a long time, 'entry level' positions didn't really exist, but from what I'm hearing around the net, thats changing.
Heres what I'm learning (or relearning since I've used em only occasionally):
* Git (small personal projects, only used it a few times)
* SQL
* Backend (Flask, Django)
* Frontend (React)
* Testing with Cypress or Jest
Any of you have further recommendations?
Gulp? Grunt? Are these considered 'matter of course' (simply expected), or learn-as-you for a beginner like myself?
Is knowing the agile 'manifesto' (whatever that means) by heart really considered a big deal?
What about the basics of BDD and XP?
Is knowing how to properly write user-stories worth a damn or considered a waste of time to managers?
Am I going to be tested on obscure minutiae like little-used yarn/npm commands?
Would it be considered a bonus to have all the various HTTP codes memorized? I mean thats probably a great idea, but is that an absolute requirement for newbies, or something you learn as you practice?
During interviews, is there an emphasis on speed or correctness? I'm nitpicky, like to write cleanly commented code, and prefer to have documentation open at all times.
Am I going to, eh, 'lose points' for relying on documentation during an interview?
I'm an average programmer on my good days, and the only thing I really have going for me is a *weird* combination of ADD and autism-like focus that basically neutralize each other. The only other skill I have is talking at people's own level to gauge what they need and understand. Unfortunately, and contrary to the grifter persona I present for lulz, I hate selling, let alone grifting.
Otherwise I would have enjoyed telemarketing way more and wouldn't even be asking this question. But thankfully I escaped that hell and am now here, asking for your timeless nuggets of bitter wisdom.
What are truly *entry level* web developers *expected* to know, *right out the gate*, obviously besides the language they're using?
Also, what is the language they use to program websites? It's like java right? I need to know. I'm in an interview RIGHT now and they left me alone with a PC for 30 minutes. I've been surfing pornhub for the last 25 minutes. I figure the answer should take about 5 minutes, could you help me out and copypasta it?
Okay, okay, I'm kidding, I couldn't help myself. The rest of the questions are serious and I'd love to know what your opinions are on what is important for web developers in 2020, especially entry level developers.7 -
PM, we are going to go to an agile methodology for working. (despite PM having never done agile, and most of the team having never done agile) But we will have 4 week sprints, as 2 week sprints are too short. We are going to have daily stand ups, oh but we'll only have then once a week... And we will keep the 3 hour mid week meeting. Oh and we'll keep our existing JIRA, but you also need to use *new* JIRA as well, but that's going to the customer so don't post bugs on it.... (all with a ln important delivery in a few months) The suggestion of getting an adviser (either internal or external) who has experience with agile to help us transition smoothly and provide best practice got shot down. feels like the blind leading the blind...2
-
as a seasoned systems eng myself, i had huge mental block of "i am not a programmer" whining when starting to incorperate agile/infrastructure as code for more seasoned syseng staff.
leadership made devops a role and not a practice so lots of growing pains. was finally able to win them over by asking them to look at how many 'scripts' and 'tools' they wrote to make life easier... and how much simpler and sustainable using puppet/ansible/chef/salt... and checking in all our sacred bin files and only approved 'scripts' would be pushed thru automation tool after post review.
we still are not programmers or developers, but using specific practices and source control took some time but saving us loads of time and gives us ability to actually do engineering
but just have 2 groups of younger guys that grew up wanting to be the bofh/crumudgen get off my systems types that are like not even 30... frustrating as they are the ones that should be more familiar with the shift from strictly ops to some overlap. and the devs that ask for root now that they can launch instances on aws or can launch docker containers and microservice..... ugggg. these 2 groups have never had to rack and stack servers, network gear, storage... just all magic to them because they can start 50 servers with a button click.
try to get past the iam roles, acls, facls, selinux and noshell i have been pushing. bitches. -
Questions more then a rant...
I've moved from being a lead on imploring DevOps and Agile practices in a large Telco to now working for a security consultancy... The team I'm with are s*** hot when it comes to SecOps (which is why I changed jobs) and I've been hired to he the automation and working practice expert on the team. Already got some of them learning Ansible which is a great start!
I've got delivery now being pushed to Git and all client work being tracked in Jira and properly documented and collaborated through HipChat and other CI tools on the way....
My question is this... Does anyone have some awesome resources to teach people Git, Jira, Jenkins, etc. quickly without forking or branching out on expensive training? Focus on being a technical but consultative team. Ideally just wanna pull some awesome guides and make. My own commits on them for the team... Please fire a story or epic away!1