+1. When I think back on the hardest/most boring classes I took in college for CS - things like discrete logic or multi-variable calculus (fortunately I never had to take differential equations, which was a nightmare story I often heard about from people in other engineering disciplines) - I think of those things as harder than most of the work I do.

But like, it also probably helps that I generally enjoy my work. For boring hard college classes, you're just like "****, this sucks", but when you get something challenging at work, it can be genuinely exciting and fun, assuming you like the stuff you work on. There's very few projects I can think of from college that were exciting and fun the way working on video games or real products has been.

Differential equations wasn't much harder than advanced calculus imo. Math physics was the brutal one for me - tensor algebra. Didn't help that the teacher wasn't very good. That was when I knew I definitely wasn't going to become a theoretical physicist.

Just before we went live with the Guinness Park Royal brewery I realised that the operator interface software I had written contained some flaws. Although it functioned fine I found this so annoying that I completely rewrote it , finishing the night before start up. The boss would have killed me if he knew what I had done. Worked flawlessly for 15 years.

I crushed diffeq. and even had to take advanced diffeq. put it this way, in most classes I needed a lot of help on my homework. in these classes the other kids had to cheat off me. so thats my brag. ofc I couldnt do physics and esp thermo for ****.

I liked thermodynamics - it explained a lot about how the world worked for me.

General physics was the big one in that for me. I never looked at anything the same after that. Instead of everything around me just existing and moving by more or less magic - I could see a glimpse of all the forces and kinetic and potential energy behind the curtain.

I've got a small gig to create an iOS app prototype. It needs to be able to manipulate and save photos and videos and talk to an API back end for some info and download some small bits of content. It's only 3 screens for now and it sounds like they don't want to bother with user signup for the POC.

Questions:

1. Should I just go with react native since I'm pretty familiar with react?
2. Or maybe just go straight old-school objective C since it's only 3 screens for now?
3. I assume you can still do that with xcode and the process hasn't changed dramatically since I last did iOS apps over 10 years ago?

I'm not super concerned with making less work when this goes from POC to MVP as that will only happen if they can get some investors to sign on, and we all know how much of a long shot that is.

I haven't done an iOS app since college but isn't Objective C ---> Swift now?

Oh yeah. Well I basically have two plans - start with a react native hello world iOS app and go from here. Or start with xcode hello world (which I guess is Swift or w/e) and go from there. I'll probably go with #1 since I assume it will be easier for the POC.

I feel like the move is react native if you’re sure it supports all features needed? I’m going to try some react native soon as well

ok so new SCRUM doctrine is 1 card at a time. yes, that means the entire team works on a single card at one time. 4 devs on the same card.

and ofc this comes after like 2 years of having it beaten into our heads to make cards as small as possible. all cards should be 2 or 3 points. and a 3 pt card for out team is pretty simple. proly not like what yall do.

so yes, 4 devs working on a single card at once.

Sounds like your scrum master just learned the term “swarming”

We dont do any kind of bs like that. Other teams do. We just have a daily standup. But I think they are trying to get more organized.

So basically no way to differentiate yourself as an individual contributor?

swarming has always been highly encouraged. insanely encouraged imo. but now we are getting into actual rules rather than just the typical passive aggressive encouragement to "self-organize around swarming" in standups and retros.

Anyone here develop on a local IDE using remote code over SSH?

Working from home and want to get this set up. I've always used Eclipse but I hear their implementation of this is pretty bad.

Anyone use VS Code?

https://code.visualstudio.com/docs/remote/ssh

I'm hesitant to switch but I hear it works really well, and apparently there is a plugin that makes it use Eclipse key bindings which will help with the pain of switching.

Any experienced mobile app devs want a side gig? It could be as little as expert consulting to help me get off the ground - to I'll just hand you over to the client and the job is all yours.

They want to do something kind of like a tik tok or Animoto (but much much simpler at first). But playing around with it I've realized this aint 2008 anymore and I need an app expert.

If anyone is super experienced in these kinds of mobile apps (media manipulation, slick UI) and wants a side gig with me involved on a limited basis as a PM/product person/dev, or I'll just hand you over to them if you want to go that route - let me know.

Otherwise I'll probably just tell them I can't do the job. I could probably muddle through a really rough POC. But I don't see how that's really going to impress potential investors any more than just a powerpoint with storyboards. Nothing needs to be proven, it's just hard.

I’ve used the remote plugin inside wsl2, it’s...fine? Don’t have a lot to compare to but I am a big vs code fanboy assuming you aren’t doing jvm work, but it sounds like you may be. Also ew eclipse.

Did you go the react native route? Or what? Disappointing to hear it’s difficult these days. Haven’t made a mobile app in 7 years.

I think they missed the 'people over process' message too.

The “people over process” concept means that a team or department forms processes based on the workers, rather than forcing the workers to accommodate a pre-designed process.

What problem are they trying to solve? Do tickets stagnate for a long time because only 1 person is working on them?

Its different and it changes over time. When I first graduated work life was much better as once 5 o'clock hits you're done with work and can do life stuff. i.e. no homework etc. I found I had a lot more free time compared to college. Also, you're on the low rung of the ladder so you're only responsible for your piece of the pie. Over time, my work has gotten more stressful as I'm responsible for more things but its usually paired with more $$ as a compensator. Also, if your software breaks in the real world you get angry customers / contractual penalties /etc. In college you just get a bad grade but can move on.

To keep my self occupied I have decided to write a bubble sort in the first language someone here suggests. Nothing too exotic please

Rust

Good one.

Edit: If not rust - Ladder Logic.

When I was unemployed I committed myself to solving as many hackerrank puzzles as I could in bash... was fun and hard

thanks this is a good response. they really like things like this. its not enough to just express why you think its a bad idea, you need a catchy buzzword/phrase and all that.

and no tickets dont stagnate. the only time a ticket takes too long is when we have dependencies outside of the program. our Scrum Master said that if we have such blockers then we should have everyone available work to overcome them. to me, this is obv idiocy. bc now instead of one person stuck, we now make the whole team stuck while we wait for the block to get resolved.

I think a lot of this process stuff is done for 2 reasons. 1) bc the managers want it to appear as if they are doing something. 2) the devs want to impeded their tasks as much as possible bc they are either lazy or suck at programming.

I am just gonna go with the flow and smile and nod and regurgitate the proper buzz words. just makes it easier.

Does your team do retrospectives? When we first started up with some agile stuff, I found them useful to get rid of the stuff that wasn't adding value and/or figure out where we were having problems and discuss how to fix. After awhile, they became less important as we started getting into a good groove on how to work within our team and we started to remove barriers/bottlenecks/etc.

But, if you aren't allowed to change anything in the process I guess a retrospective is pointless.