breeny592

>Another JIRA flaw: highly formalized process is usually a hindrance, especially considering who in your organization invents, applies and benefits from process. Hint: middle managers.

This just reads as someone who hasn't had to actually think about what is being built, and who is paying for it. Effective teams are more than just "developers write and push code" - it's about being able to predictably say we are implementing this feature (or fixing this bug), therefore it will be available to customers at X time. As organisations grow, it becomes more and more critical to be able to predictably forecast the work that teams will complete, so that the right work can be planned out and roadmapped.

I had plenty of problems with this article, but this one stood out the most.

It's still used in quite a lot of enterprise production applications, would say it's on the decline but no where near dead.

I think pacala's point still stands - if you rent hardware, there is still a larger effort involved around running scalable services (DR, auto-scaling/load balancing, deployments etc). If you rent hardware, you likely will need a larger dedicated % of resources dedicated to maintaining that, over OOTB service providers.

Edit: got user names wrong

Context: I work on a large CMS powered site

We have a company wide rule of no IDs in styles - we actually lint for them. As a front end team, we can't be certain that there will only ever be one of a component on a page at a time. Sometimes we can be mostly certain, but the content authors can theoretically do anything, and our job is to provide them flexibility whilst keeping the site looking good.

Modular CSS would be a God send for us, would be able to handle a lot of things much cleaner but sadly the current build of the CMS doesn't allow for it.

In small sites, or anything with static content, IDs are more than valid. But it becomes a lot harder when dynamic content, especially dynamic components, come into play.

And it does a poor job in that regard too.

- CSS modules promote more re-use if structured correctly - BEM and the like exist to do the literal opposite, to isolate styles to minimise regression and site wide issues at scale.

- Visual consistency is enforced in CSS usually through variables to make sure spacing, colours etc. are the same, with a default set of global styles. There is literally no difference in a modular approach - you can easily have global styles to theme, and then isolate and import the more specific rules as needed.

This article reads as "I learnt how to do CSS this way so anything new is scary and wrong"

Some developers at my workplace are very resistant to change ("why learn ES6 when ES5 works fine" is a classic line we used to get). Trying to move onto a module based CSS approach (whether thats CSS modules, CSS-in-JS etc), and literally one of them went "but you can handle that with namespaces, why not just do that".

Don't understand why people will willingly do far more work, with more risk, and more prone to error and bugs, than "learn" (using that liberally given how trivial it is to pick up) a modern approach that solves problems for you, so you can get back to making features, rather than dealing with quirks of older approaches.

CSS modules is pretty clean, but disagree that JSS/styled-components are "cringeworthy". They're very powerful, especially when combined with React component props - i.e. let's say when a component has a prop active, that when true we want to change the color on something. A traditional way to handle that would be by toggling some active class, however this creates coupling from the prop to a class, and then the style to that class as well. With styled-components, you can remove one step from that with the classes, one less thing to think about (the developer doesn't need to think what classes are needed with what props, and then what styles apply on those classes).

Among many other solutions as well (like JSS).

CSS-in-JS !== inline styles, at all, yet seems to be a rallying call for people who fear "something different".

That's what got me with it - the author states as if it's fact that best practice for CSS-in-JS is copy and paste, but I've never seen anyone advocate for that. Especially with Webpack etc, it's trivial to just import JS styles and re-use.

Sealed the fact to me that the author is biased towards CSS, without actually knowing anything about CSS-in-JS solutions.

Except to their own companies bottom line, generating millions in revenue?

Releasing less often is a way to guarantee that bigger bugs will get through at some point, requiring hotfixes etc. The more you release, the higher quality releases you have, and the smaller production incidents.

The point isn't to remove QA, it's to trust that the automation in place is high quality and will catch the majority of issues before they are issues (i.e. if something makes it through the automation, then it should be caught in the internal release, or at least the 3% canary group), and then on the back of issues, make the automation more robust.

The more people who are introduced into a process, the more likely it is to fail at some point - the fact is that Facebook has a pretty low rate of huge production issues compared to most software companies, they must be doing something right.

I find a big thing too is building up that mindset of always roll forward. Bug in production means next production build will fix said bug. No hotfixing to say the release is done etc.

Completely agree that from a tech side there is no excuse, however a lot of QA culture has persisted through orgs and they want to keep that feeling of control (even though automation does it way better than them)

Exactly - releasing is the easiest part of the process.

A lot of orgs don't have continuous deployment because of reasons such as:

- they don't have a good enough automated testing suite (or at least don't trust it fully), and thus rely on "sign offs" to have people commit to saying it's quality

- they don't measure in production properly (no real error alerts, no way to measure release success), and often deal with things in a "go or no-go" type way

- they don't canary test. To me this one is critical - the only way to get real production use is to have real production users actually using the site/platform/app, just a sample of them, to see what could go wrong, especially with new features

A lot of managers I've worked with are shocked whenever I pull out the "continuous deployment is easy. doing it well is hard" line.

On a more macro scale, places I've worked have had people set goals across a longer period of time (3, 6, 12 months) that are measurable and have direct actions. I've found those to be quite good for myself as a developer as a day level measuring doesn't really capture what I do and what I achieve.

Ignoring fluctuations in performance at a day level (somedays no progress goes forward and it's more reading and thinking, come in the next day and everything just lines up and can power through a ton of work), I find that by virtue of working in a ticket based environment (user stories, anything involving Jira and/or Trello etc.) provides enough day to day ability to track how you go, so I like to set goals like in 12 months I want to have learned a new framework and worked on a project with it, or in the next 3 months I want to have re-factored this legacy code etc.

Goals to me should always extend past what you're expected to do, and instead show what you want to do in addition, whilst still adding value to the org you're at.

"The cull", aka death from alcohol poisoning on NYE.

One of the most valuable skills I always try to teach junior (and sometimes not so junior) developers is not only how to abstract your problems (as the author points out in this article), but also how to follow a related chain. For instance, let's say you have an issue with some event not firing in an old browser, and as you research it, you see the same answers saying a concept you haven't heard of before. Looking that concept up (and either reading about it or following some tutorial) then teaches a wider understanding in that domain, instead of a bandaid fix that the developer doesn't understand but fixes the problem now.

The role of a developer isn't just about solving problems, but to understand why the solution works as well.

HowToBasic's guide to creating a Todo MVC React App

1. Open editor of choice

2. Slap the keyboard with a raw fish

3. Crack a raw egg on the screen

Separation of concerns != splitting logic from presentation.

SoC comes from MV* architectural patterns. In real world front end applications, people who separate based on the file extension often end up creating JS files that breach SoC - they are both handling view rendering as well as application logic inside a JS file.

If there is something that should be conditionally rendered, using JSX is no different to a template language - only thing is the variable you're using to do that isn't actually in that file either (so, over-separation of concerns?). Both of these are logic - one handles it inline and the other handles it across multiple files.

No one is advocating that JSX should break SoC (a component should never talk to an API, or implement business logic - it should be responsible for given a set of inputs, it will render the same output time and time again).

Different strokes for different folks - my thought to that is pretty much that I don't really care what the result will be on the grand scheme, but more specifically isolated nodes and how they will interact with my model/data etc.

Having the ability to see exactly what's in scope right next to the markup to me is invaluable - one of my biggest dislikes in templating languages is swapping between files that define the data in the scope and the template to use said data.

Not to mention that if a section of markup gets too big, you can break that down to it's own method that returns tiny snippets so you can have really simple methods that end up creating the more complex end result i.e.

_renderXOrY = (thing) => { return thing.isX ? <X thing={thing} /> : <Y thing={thing} /> }

//inside the render method <div> {listOfThings.map(thing => this._renderXOrY(thing))} </div>

I personally prefer this because when creating the top level of a component, I largely don't care about the individual elements of a list, but rather am structuring how that list will be contained etc.

And let's not discount then the value that JSX brings of being able to easily unit test that your conditional logic renders the correct output easily (Jest + Enzyme = easiest tests I've ever had to write, bar simple functional checks).

Checklist:

- [x] Working in a consultancy

- [x] Government client

- [x] No direct communication with the users

- [x] Waterfall project

- [x] Short timeline

- [x] Understaffed

- [ ] Clear requirements

Was definitely delivered on time and on budget...

I'm confused on how an employer is not a "jobs program" - they literally employee people, and are responsible for that employees growth and career opportunities (if they value having low staff turnover and achieving better outcomes for their business).

I agree with yawaramin as well, happy employees are better performing employees, and can speak from experience with working at places that value individuality versus strict top down directing of behaviour, that the companies with that flexibility perform much better, at less cost, with much happier employees.

It's not about lowering expectations, it's about changing how you look at them - look at the outcomes and measure those, not the journey to achieve them. When you start focusing on outcomes as teams, you open the door to diversity, which leads to diversifying your ideas and solutions to problems - ultimately leading to better outcomes.

I think it's a pretty bad false equivalence to liken physical sports to ability in the workplace, purely because one is specifically _the peak of human ability_ and the other is outcome driven.

Taking your example of say, sprinting - the outcome is to cross the line 100m down the track. I would say pretty much everyone is capable of doing that one way or another. When you apply a performance lense that says you need to do it in X seconds, then you're saying "we only want our definition of the best to do this task".

Bringing it back to the workplace, a lot of jobs in tech (and other sectors too), suffer from trying to apply a one size fits all performance lense over the actual outcomes. "Sure this person did their job, but did they do these metrics that we've decided we value". A large part of diversity is acknowledging that the lense that you view people through is not going to apply to everyone, and accepting that you need to focus on the outcomes.

It's bit different if you work with them (or in the same company). Linus has a certain, style, to put it nicely, but in the broader open source community.

The key point is that this is likely the first time these two individuals had communicated - she effectively introduced herself to this person by saying "you are wrong", or "your work is incorrect". This isn't a professional way in a business to talk to someone. Even a simple greeting and explanation to say "I have some experience in this area, and here's some suggestions that would improve it" is infinitely better than the framing she gives: > I was very disappointed at this 101 mistake > sadly opened an issue referencing the question The emotions portrayed there give a good indication to the tone that the writing likely gave - instead of being constructive it could easily be perceived as hostile.

Yes, I think the data scientist over reacted. But I don't think her tone or approach was at all appropriate either.

I would argue that the world has moved on to expect more open APIs - events like Google I/O and event Facebook F8 reveal quite open technologies that encourage open innovation in a web context. WWDC, at least from a software side, is the closed garden and from a "next step forward" perspective, less interesting.

As a Mac user, yes I'm interested in the next version of the hardware, but the software announcements are only useful to the users of their hardware.

If Apple came out and said iMessage is now an open platform, then discussed their new chat capabilities, it would be a different story.

I'd propose a hypothesis that yes it does, for a couple of main reasons:

1. Concentration of job market - a lot of industries only exist (or at least, in a large enough volume) in the larger cities (e.g. financial services, tech). I'd say this is largely coupled to the location of higher education, where there is (relatively) less tertiary education once you leave the major cities.

2. Desirability of location - infrastructure and general "way of life" tends to lead people to wanting a more coastal existence. Australia didn't have the boom of city development in our regional centres, look at towns that are considered large in rural Australia, and they barely compare to even the outer suburbs of the major cities.

As much as our deputy Prime Minister would argue "just move to the country", it's not a realistic statement without addressing massive shortcomings in the long term planning of our rural areas.

Anything where the customer and their real needs is not the focus. If a product places sales or money above the people it's dealing with, I'm not interested. Ironically, I now work for a bank - just luckily a bank that has very good ethical practices and takes their responsibility to their customers very seriously.

I think you left the /s off your comment

Not to mention it's something that when making custom components etc., you will be able to do if so desired. A good component structure and composition enables you to handle Android versus iOS, but still have a large amount of sharing available.

I consider this similar to the Xamarin structure of Apps where you have Android and iOS projects, and then a shared common library.

A note on the require issue: this makes sense if you think of requiring as it's compiled equal - importing.

You can't dynamically import dependencies - so if you're wanting to load JSON dynamically you should be using other mechanisms (even if it's just a FS operation or having an internal service to return JSON).

Someone in the comments of the post suggested the same thing - people who criticise React (or any framework really) of "taking too long to set up" says one of two things to me:

1: they're too picky in what they want to use generators like this (or one of a billion Yeoman templates) - which then says don't complain something takes too long to set up when you're the one adding complexity

2: they count learning new methodologies/frameworks as part of the "setup"

In the case of #2, what you know is always going to be quicker than what you don't. Complaining that "it takes too long" should be rephrased to mean "I don't have the time to learn something new"