Perfect storm for the company I was working for. Had their worst fourth quarter in company history. Purchased another company in January as part of a pivot to a more profitable business model. They were a bit desperate to get the deal done, probably didn't even consider what was occurring in China at the time. They had significant operations in Southeast Asia. As far as I knew zero planning had been taking place until it was too late.
Essentially all revenue generating operations halted as of March 16th.
I was unfortunately leading the charge in a newly created division. We were not generating revenue yet, so the hammer fell for all of us.
Got a new full-time gig working on an Angular 5 app about 3 months ago (they're behind in the upgrading to 6/7 for god knows why). Coming from working on an angularjs app for around 3 years.
I'm unimpressed with essentially the entire framework. It feels over engineered and overly complex with little benefit. Note that I'm saying it feels that way, maybe at some kind of scale this is very helpful, the codebase I'm working in is about 150k sloc.
The biggest gripe for me is how unintuitive it is to compose and reuse bits of UI. Having written almost no React, and absolutely no React professionally, I understand how to compose react components and the basic patterns for communicating between them. It's just not as easy in Angular, so for the most part it just doesn't happen (at least with the devs I'm working with). Patterns such as render props, HOC, stuff like that is not straight forward in Angular. I'm probably not thinking in the "Angular" way or something.
The dependency injection patterns that Angular is so fond of is something I'm not enthralled with as well. It made more sense in angularjs since es2015 modules weren't prevalent at the time, it really solved a problem there. I don't think it's as helpful in Angular now, and is yet another framework specific thing you're going to have to grasp at a decently deep level.
I work right next to another dev that was hired about a month before me. He's coming from writing React for the last couple of years, and angularjs was the first SPA framework he ever learned. He is constantly cursing how Angular does just about everything, he's not a happy camper.
If I was calling the shots today I would not use Angular for my SPA framework.
Are you using Redux for state management in react? You mentioned the "basic" patterns for communication between components. I assume you did not have complex state management requirements.
The DI framework in Angular is not concept novel to Angular. It's essentially an implementation of the DI.
This analogy is one of my personal favorites for software development. The machine that is going to be running the software could be considered our building. The hardware of the machine is designed to exacting specifications by people that typically hold university engineering degrees and is much more reliable than software typically is, it has to be or nobody would use it. Failure of the building is catastrophic to the tenants.
A process could maybe be considered a room within that building and adding functionality to that process is akin to adding furniture to a room, or I guess, doing a buildout for a tenant. You add specific furnishings to help you accomplish specific tasks within that room.
This analogy breaks down pretty quickly, but think about the room here. I can now explain to a non-technical person that this software (a single process in this case) is like a broom closet that we've shoved full of old furniture for the last 5 years. Prior engineers have stacked tables to the ceiling, filing cabinets have locks without keys. We don't even know what's in the back of the closet at this point, and getting a peak at what's in the back will require unpacking everything at the front.
On the other hand you could have a different room. It has doors for egress and ingress. It has glass walls so we can see what's happening at all times. We carefully arrange the furnishings for efficiency, and can swap out old furniture for new in a matter of moments. We regularly clean the room, removing unused/aging equipment etc... When people enter that room to work (end users) the workflow is effortless and intuitive.
So as a software developer/engineer or whatever you call yourself, we're more like the contractors that buildout interiors for specific use cases. We equip the rooms for doing specific jobs. You give us the building or even just one room and we'll make it useful.
The company I work for just started the process of completely reworking how the development team's impact/effectiveness is measured (along with each member of the team as you would imagine), so your comment really peaked my interest.
What did you end up measuring? How did you measure it? We've been debating for the last few days on how to measure the outputs and their real business impact without getting caught up measuring the inputs that may or may not really matter (commits, loc, story points, etc...).
For context this is an org that has been, historically, in the dysfunctional area of the operating spectrum, high employee churn, lots of technical debt, no testing to speak of in flagship product, high concentrations of knowledge held by single individuals.
We have somewhat coalesced around the idea of dynamically assigning business impact metrics on a per feature/product basis (if we build this thing we would expect to see metric x, y, z go in said direction). In addition to those metrics we are thinking of also doing something along the lines of an NPS (net promoter score) score that would be given to the feature/product by the end-user. Taking both of these into account would then score the development teams effectiveness/impact.
In addition to the outputs mentioned above we would also be tracking the inputs, but more as a historical data set, to see if there are any correlations between our inputs (commits, loc, story points, etc...) to better NPS and business impact metrics.
I'd love to hear any feedback, experiences, advice.
P.S. Team size is 10 devs, core team of 4 in U.S.A co-located, all others remote international.
> For context this is an org that has been, historically, in the dysfunctional area of the operating spectrum, high employee churn, lots of technical debt, no testing to speak of in flagship product
> P.S. Team size is 10 devs, core team of 4 in U.S.A co-located, all others remote international.
My advice would be to bring in a good dev manager and stay away from trying to narrowly define dev productivity metrics.
A good dev manager will be able to bring you up to average and fix the obvious problems.
If you are part of a larger company then the business side is probably using OKRs (objective-key results) or something similar to track at a higher level. Start looking at and making sure your team is contributing to these.
As a senior manager your teams self-assigned dev metrics are meaningless to me. It's not going to be enough to justify more staff, pay rises, different work, etc.
You're probably right, I'm the sole full-time vim user at my place of work (primarily a python shop). I was vindicated in my choice yesterday when somebody forgot to pay off the credit card and the jetbrains license payment bounced, so nobody could work because their pycharm locked them out. I get why people love pycharm though, it does a good job, but I always felt like it was such a pig. Plus you can write some hairy code because the IDE will just let you prance through it without a care in the world.
A couple of posts that really made this click for me (just beginning my programming career). This is javascript library, but the concepts do translate functional programming in general.
After reading this series of blog posts and using Ramda.js for the last year or so, I can see the value here. But you do have to "get it" which means learning additional concepts, if the additional learning isn't a burden to your team (I hope your team isn't averse to learning new concepts) then I think it's an asset to be used when it makes sense.
Thank goodness I decided to bite the bullet last week and make the jump to v2. Upgrade took a while but was rather painless thanks to the great migration guide on the new documentation site.
If you are using a ton of loaders that aren't v2 ready you may have a more painful experience, you'll have to get familiar with the LoaderOptionsPlugin.
If you're newish to webpack it could be a frustrating experience.
Shout out to the webpack team though, It's an impressive tool.
Essentially all revenue generating operations halted as of March 16th.
I was unfortunately leading the charge in a newly created division. We were not generating revenue yet, so the hammer fell for all of us.
Stay happy, stay safe, and keep hacking!