wouldn't this be a good thing? I prefer my circadian cycles not to be disturbed by artificial lights and if i am reading this right, it is what happens with led lights. this would be different of course if i had no access to natural lights. glad to be corrected :)
Demonizing offshoring, nearshoring or reducing it to a cost saving strategy is ... terrible way of seeing it. It is about talent and talented people. And talent is everywhere. I say this because our company does nearshoring for the US from Argentina and Chile to US companies. We don't try to be the lowest price, we try to be as good as we can. If it saves our client's money, much better. But our goal is not to save our clients money: our goal is to deliver as much value as we can. We focus on frontend: we have 2 master classes a week about topics like debugging, communication, teamwork, data viz, javascript... We have english lessons to improve communication skills. We try to give back contributing to frontend libraries by fixing bugs on those libraries and sponsoring their devs. We have created open source tools like https://grid.layoutit.com/. We put our souls on this and we are very fortunate our clients trust us and value us. We are not the only ones doing this and doing it as good as we can. The base of business relationships is about mutual benefit.
Thanks for sharing it. We follow quite the same best practices both for our Dallas and Ukrainian offices. And yes, we are about the value as well. But usually, companies outsource either to cut their costs or to reach talent that is not available locally. That was the reason why we outsourced.
The problem is not about react or not react, the problem is how to align big team to create an application.
If a big team is going to be working on it you need some strong opinions around it. Do not mess with the package.json. I cant stress this enough. Actually, the most important file in your whole application is the package.json. Almost nobody should be allowed to add additional dependencies because is the main point to generate chaos and problems in the long term.
Also, the design system matters a lot. Have a small team working on the UI components to tailor and extend the design system. Dont allow the rest of the teams to extend the ui components with new libraries. Stick with the design system
as much as you can. The rest of the teams should minimize the amount of CSS they have to write to components placement.
Usually the datagrid is the soul of any enterprise application. Choose it wisely and be sure it covers as much functionality as you can and also that it is customizable on an "easy" way. There is always a team with the need of a datagrid that sorts, groups, filters the data with dynamically adjustable cells and multi header items without pagination. Welcome to hell.
Use one pattern: hooks, central store, whatever you want. If at some point you have to change it you have to know which teams are using which one. Dont allow team members of the same team follow different patterns. Code reviews must take care of this.
Hope this small tips help one or two teams out there. I have worked on the migration of 5 big enterprise applications from angularjs to react or from legacy desktop application to react or from server pages to react.
I made a lot of mistakes that costed a lot of dollars. I have tried to learn from them. Also, dont take me very seriously, I am pretty sure I am about to discover another mistake I have made.
> If a big team is going to be working on it you need some strong opinions around it.
You are just stating the problem the article complains about.
Whose opinions are those? You need to take a lot of decisions.
Moreover, those decisions which seemed good (to you...or the one that dictates those strong opinions) at the time you took it, are not valid just months or years down the road. So you will need to reevaluate them periodically.
Moreover, even if you are happy with your decisions, you might be forced to take them again, because the library went out of fashion, unmaintained, or the developers just stop responding to issues and ignore you completely. This is already happening to a project I work with where the react-router developers just went to build their own nextjs competitor and stopped responding to issues. Same with styled-jsx from the same next.js team, not even themselves seem to be using it anymore.
This never happened to me using Rails. True some gem might go away, but at least it usually is some helper thing and not the core of my f*ng application. Same experience with django and many other uncool stacks.
So, yes. React is amazing if you are facebook, google, amazon, building a side project or just working for your own resume. It is not good for the average business. It is not good for enterprise applications.
the person who has the authority to call the shots and leads the project.
The error is right there in the article:
"After nine months, we have more than 50 pages created. The developers notice that function components are as good as class components and start using them. So, now the project no longer follows the original coding guidelines. It’s more like a personal choice for each developer. And for me, that is OK."
This is where the screw up happens. This is not okay, and as the person responsible for the architecture the author should have made a clear and concise decision and then get everyone to comply with it. You cannot let your developers run wild and then complain a year later when everything is a jumbled mess. Even more opinionated frameworks won't save you because the application is so large it likely would have happened regardless.
I am a rails developer myself and I love rails, but this applies to rails too. Actually rails lowers this problems a little because it is an opinionated framework but you could same to Angular for frontend. In react case, you just have to build that yourself with the pros and cons.
I’m sure you make this comment in good faith, but no - every React project I’ve been part of sounds very similar to this. The others, not so much, and I’ve been doing frontend for over a decade. There is a distinct amount of churn and excess of dependencies / eternally unsolved problems that is particular to the React ecosystem.
Note that your suggestions do not address the main problems: time spent upgrading libraries, brittle dependencies, and linear degradation of performance and stability. Code standards and code reviews cannot help when the problems come with the standards.
IMHO, there's a bit of an irony that I see with a lot of React projects: people often say that w/ vanilla JS, you end up reinventing wheels poorly, yet this is exactly what a lot of React projects I see look like: people that don't really have framework-building experience attempting to cobble up something similar in scope to Angular or Ember by using React + a bunch of other libraries (often libraries they've never used before).
There's certainly a case to be made about large teams being a problem of their own, but FWIW, a lot of projects _don't_ have large frontend teams (I'd say 1 to 3 frontend devs is fairly typical). Standardization _across_ teams can definitely be a problem, but at some point one has to wonder if it isn't more sensible to just have each teams develop separate apps that load in separate pages, or, you know, just use a more batteries-included, prescriptive framework.
It's been awhile since I've worked with npm, does it still do that thing where it changes package.json every time you `npm install`? I remember writing a script to discard package.json edits because my PR wasn't supposed to upgrade any libraries.
I never recall it doing that, you may be thinking of the `package-lock.json` which does get created still. It basically creates/records hashes of the packages that get installed when `npm install` runs. Shouldn't always be changes there but depending on how version flags are set in `package.json` an `npm install` could create new `package-lock.json` values if there's a newer version in the repo that gets upgraded/installed.
We have a private local package repo at my company. Some developers set up their npm registry, or had it set up for them, with registry=https://.. Others have registry=http://...
Regardless of whether or not Strict-Transport-Security is enabled on the server, npm will still record the protocol as-is in the package-lock.json file.
Half the time a PR will include a package-lock.json with every "resolved" field having the protocol gratuitously changed to the other protocol.
We have a pretty similar issue at work where our package-lock file switches URLs between npmjs.com and our own npm registry. Can you elaborate a bit on what the issue is and how to solve it?
The issue is that some developers have configured the registry field in their .npmrc file incorrectly. Ideally, sending out a memo telling everyone to fix it should do it. If not, one way to fix it is to commit the .npmrc with the correct configuration (assuming it doesn't include secrets). If all else fails, an ugly hack is to make a preinstall hook that fixes the .npmrc file.
you have to use `npm ci`, which was added a few years ago. my team ran into that kind of issue right after `ci` was added, thankfully, or we would've had to do something similar.
i now have this aliased to `ni`, so i get to say `ni` to the app often.
This was my biggest take away from this article too.
When you have a big project, you have to keep a consistent architecture. You need to keep using the same tools and patterns so that you have cohesion in your code base.
The worst thing about new architects on long lived projects is you typically get 2-4 ways of doing the same thing. If you're going to do that it needs to be so good that you don't mix and match.
If you are going to mix and match, you need to have a solid approach to splitting your dependencies, one way I'd have looked at doing this is by splitting this into multiple sub SPA applications and each mini project would be able to conform to it's own standard as long as it could interface with the glue application, this is by no means foolproof, but it gets you a lot closer to a maintainable situation from my experience.
Why I like this approach is that I saw a comment from someone saying they'd hate to be on a team with a uniform style. I completely get that, innovation is super important, but you have to build boundary layers between the different styles so you don't end up building such a hodgepodge of dependencies that you can't get things to work anymore. It also keeps your build times down and reduces time to get started working on your module.
Again same comment you made, I've made mistakes, trying to learn from them, maybe my current approach is bad too and there's a better way.
Use a monorepo with many `package.json` files. Then someone working on a data grid component for example can add the packages they need for that component and no one else's code will depend on it and it won't break anyone else's.
You are describing a job I really would hate: no inovation, no try. If you can't even change the package.json without getting everyone angry, it's a horrible team to work in.
Innovation doesnt come from adding a library to the package json.
You are a member of a big team, not a single dev on a pet project. Innovation is on the product, not in your developer experience (unless you are creating a developer tool). Consensus to make big decisions is not the way to limit your developer skills is the way to align a team to achieve a common goal. :)
I love this way of phrasing it. I have these types of arguments with a particular type of colleague often, and this is a missing part of my explanation script.
It depends on how effort do you want ton invest on your data visualizations. If you are looking to create a dashboard with some charts and not very specific UI requirements on them you can use a data viz library (recharts, vega, C3, highcharts, ...). If you need to go deeper with more specific requirements on the charts ui, the interactions with other UI elements and/or optimize for high volume of data D3 is the best path. If you want to create your own unique consistent experience you would probably even invest on your own library on top of D3. You can have the base of that library in 2-3 months period with the basic charts: barchart, linechart, scatterplot, pie, ...
I run a small dev company. This is the first lessons we teach our programmers. If your code cant be understood by someone else with minimal efforts it is not good enough.
Do you maintain a high-enough level within the team though? Most "clever code" I've seen is called clever by people who are not yet proficient enough in a language to understand it. So with unskilled programmers pretty much anything that isn't straight combination of classes, loops and conditionals will be considered clever. There's a tradeoff here - I get the business reasons why one may want to have the codebase at the "lowest common denominator" level for the team. But then again, programming is a craft, so that person who says lambdas in Java are "clever code" (real example from my work) should IMO suck it up and spend few hours learning; then the code will stop being "clever" to them.
> Most "clever code" I've seen is called clever by people who are not yet proficient enough in a language to understand it.
My interpretation is the opposite. I call code "clever" after I've understood it. I agree its not universal, but in all the cases I've seen it used so far, its been another way to say "This could have been written in a simpler, more readable manner. And it should have been."
Not every company wants highly skilled programmers. Depending on the complexity of the project, and cost of defects unskilled programmers may be the most cost effective.
I know. Took me a while to realize it and understand why companies think that way, but it boils down to the fact that as programmers, we're not paid to do a good job, we're paid to do a good enough job. Those two goals are very often at odds. It seems to be a typical clash of craftsmanship with market economy.
Another articulation is - we aren't paid to write code, we are paid to build stuff.
Authors get paid to write prose people can read - the readability of our work only 'matters' insofar as good craftsmanship practices help the team maintain velocity over the long haul.
That's a good point. There is also a fine line between craftsmanship and intellectual self-gratification at a customer's expense. Doing a good enough job that solves a customer's problems without gold-plating or unneeded complexity is what professionals in most fields are ethically required to do.
As tired as I am of seeing sloppy code, I also intensely dislike the trend at the other end, of creating a half-dozen RESTful microservices and throwing away the relational DB just because it seems cool, maintainability be damned.
I'm hopeful that software development (especially business software development) will someday escapes it perpetual adolescence, and will develop stronger ethical standards.
This is a very delicate subject. If the program is using language constructs and can't be understood because the reading programmer doesn't know it, then who's fault is it?
why have multiline if/else when a tenary operator can do?
I rather read a = b ? c : d; than possibly 4 lines of code, p/s ignore the names of the variable.
There are plenty of code out there that are so easy to understand if you read them one line at a time, but very difficult to see the big picture, say there is a method being called as follows foo->dostuff(bar).
The issue is there is so many layers between calling dostuff() and something interesting happening. because dostuff calls nextstuff() and nextstuff() calls stuffafternextstuff(). The code is easy to read but terrible and tough to unravel.
There is only so much anyone can hold in their head at once, a bit complex but 2 layers deep is better than so simple to understand one line at a time but 10 layers deep.
Bertrand Meyer and a few other notables talk about separating decisions (policy) from execution, which happens to address some of those issues, because the decide and act become sibling function calls instead of a deeply nested chain of responsibility arrangement.
It also happens to make testing a lot easier.
It's probably just a crystalization of the old idea of keeping business logic out of your code, but somehow misses the open invitation to create rules engines...
I agree to a huge degree. If your code is obscure and overly complicated then it's probably not a good idea.
To play the devils advocate though and show that sometimes we have to challenge our rule set I'll give an example.
I worked in a C# shop where they were using Webforms for a massive application in 2012. Their developers were old hands at winforms and didn't like to learn new things in the framework. So myself and another developer started introducing things such as Linq, javascript, and other novel concepts.
Because some of the old hands there didn't understand it we weren't supposed to use it...
I also attempted to get people to write more testable code so that when we do make a change it doesn't break something in a different section of the codebase. I got push back on everything.
So I'd amend, "If your code cant be understood by someone else with minimal efforts and/or explanation it is not good enough." Because sometimes people don't understand the code because they don't have an inquisitive nature.
Hell, there were public, senior, MS hires that fundamentally didn't understand "var". Let alone how LINQ worked or anything like that. On HN last month, someone was critising the use of flatmap as being too complicated. Despite the type signature making it clear what it does.
There's probably lots of apps that need real boring code, so you can add yet another case to the data entry app to handle the extra 2% sales tax for a certain county in Wyoming.
I can't imagine that there's any apps anyone wants to work on that have a low bar for "cleverness". And it's mostly a one-off thing. Learning language features should not be the bottleneck on getting someone up to speed on a project. On any system of any fun or size, the domain-specific stuff probably dominates.
(Anecdote: I've had several people come onto projects with F#, fresh, no FP/F# experience. It's been very easy and after a while they wonder how they ever put up with C# in the first place. And the people that aren't able to do this, I wouldn't want to hire to work on C# either.)
This needs to be seen in context though, because it critically depends on who "someone else" is. A category theorist will have a much more abstract view of a Haskell program than your usual developer for instance and something that seems tedious and unnecessarily technical to one can actually be a useful abstraction to someone else if one knows how to use it (e.g. see all the monad submissions).
There's a cost to that too, unfortunately. Longer code may be easier to unserstand line by line, but the sheer volume of lines can make it harder to comprehend. Terseness has its advantages.
Usually, making good developers write code for less experienced developers makes the code quality worse. OTOH, it can then be maintained by entry-level developers.
I'd argue there's a difference between being concise and being terse. I think that's what's at the heart of beautiful code: It expresses its ideas in a very simple, concise manner, without sacrificing readability. ("As simple as possible, but not simpler")
If you are indeed Mexican, the subjunctive shouldn’t apply anymore, as there is no doubt/speculation/hope involved. (Caveat: Non-native and also a bit rusty)
"fueras/fueses" would be the right verb form, but that would be equivalent to "How to vote for Trump if you WERE Mexican" as opposed to "How to vote for Trump if you ARE Mexican".
Vote buying and selling is election fraud per 18 U.S. Code § 597 [1]. In fact, it's not even legal to make the offer, in either direction:
"Whoever makes or offers to make an expenditure to any person, either to vote or withhold his vote, or to vote for or against any candidate; and
Whoever solicits, accepts, or receives any such expenditure in consideration of his vote or the withholding of his vote—
Shall be fined under this title or imprisoned not more than one year, or both; and if the violation was willful, shall be fined under this title or imprisoned not more than two years, or both."
reply