I spent a lot of my career trying to find roles where I didn't have to deal with people. A lot of time in startups and small businesses, where my job was to just build. At a certain point, there weren't that many new technical problems I was running into, so I decided to work on team-building skills. Over the past few years, I've been managing engineering departments, something I never though I would do.
It's usually people. Sometimes it's opportunity. But it's usually people.
I've ended up with a lot of thoughts on the topic, but I'm not sure how best to convey them, so I'm doing to rant in dot points:
- People rarely leave because of technical decisions. Most people are appeased when you can explain the rationale, even
if they disagree
- Good leaders make or break an organisation. They inspire people, they give them a cause to rally behind. A lack of good leaders will kill culture within a year
- Good leaders own problems and will find a way to solve them, they won't accept the status quo
- Bad leaders will tell you why a problem is not their fault, and do nothing to fix it
- Good leaders need good leaders - it starts at the top. A good CEO will change your worldview
- Good leaders-of-leaders know everything is kind of fucked, and appreciate leaders who are actually trying to improve things, without expecting they're going to get everything right
- Leaders need to really believe in their cause. People know when you're faking it
- Culture is not a by-product. It's the product. You work hard to create a good culture, and it can disappear very quickly. Building good culture is how you build good teams. You can't work around a bad culture
- Most of being a good leader is just turning up. Be there for your people, listen to them, try to make their lives better. Make time for them. Show them you care
- Regardless of all of this, people will leave. Sometimes because the company isn't a good fit, sometimes because they're at a different point in their career. Attrition is healthy, you just need to keep a pulse on whether it's happening for unhealthy reasons
In summary: yes, it's pretty much always people. Building software is easy. Building a healthy work environment is hard. Most people focus on the easy problem.
I didn't choose to adopt GraphQL, but I joined a company where an ex-developer had integrated into what was at that point a core codebase. They didn't add it due to any particular merit, they just wanted to play with shiny new technology. The codebase also had REST endpoints, but GraphQL made up the majority of the API, so we decided to just run with it and deprecate REST. At the time the decision we made was arbitrary.
This turned out in retrospect to be a good call. The primary consumers of the API were a set of Android and iOS apps, and integrating GraphQL into mobile apps is a pleasant experience. You can generate your data models from the graph schema. Tools like GraphiQL allow developers to explore and play with your API, substantially reducing the amount of documentation needed. The mobile team much preferred working with GraphQL over REST.
On the backend, GraphQL has a bit of a learning curve. The resolver pattern is powerful once you understand how to use it properly, but also easy to misuse. The most common source of problems is developers not understanding Graph's batch resolution mechanism. Developers accustomed to building REST APIs rely on preloading data, which is the wrong approach when dealing with GraphQL.
As a simple example, maybe you initially build a Graph query where you load comments like this:
But later on, you decide you want to allow a user to load their comment history directly:
query Comments {
user {
comments {
message
}
}
}
In the first example, an equivalent REST API might load comments via something like posts.preload(:comments), and when the second query is built you'd use user.preload(:comments). But the way to solve this problem in Graph is batch resolution - get a list of comment IDs you want to load, then call Comment.where(id: comments_ids). Your comment loading is now context agnostic.
Another related problem is that it is easy to create N+1 queries. This also stems from a misunderstanding of batch resolution - reusing the above example it would be the equivalent of calling Comment.find(comment_id) for each ID instead of Comment.where(id: comments_ids). My first few months working with Graph were often spent fixing N+1 queries. As much as I try to explain this problem to new developers, it's one of those things that doesn't click for them until they cause the problem and end up having to fix it.
Once you understand GraphQL it's a nice technology to work with. In the early stages it can be fairly easy to shoot yourself in the foot, you just need to build up enough knowledge to avoid the common pitfalls. In general, GraphQL APIs are harder to build than REST APIs (mostly because REST is the default for most frameworks). If I had to start a new project today, my decision on whether to use GraphQL would be be determined by questions such as:
1. How much control do I have over the clients
2. Are the primary consumers native mobile applications
3. Is flexibility important
4. Will API documentation be required
It definitely requires more work. If you're starting from scratch, you need to either read the API documentation or makes calls to the API to understand the data you're getting back. You then need to build correctly typed data models that match what you're expecting the API to give you. There's plenty of room to make mistakes as it's a manual process.
With GraphQL you can take the schema file from the server and use it to generate your data models. You get the data models for free, everything is correctly typed, and as long as the schema you're using is up to date you have a guarantee on correctness. It also makes finding changes to the schema easier in the future, as you can effectively do a diff.
We also use GraphQL on web (the exact same API as mobile) but we don't realise nearly as many of these benefits. This is probably in part because we haven't invested a lot in tooling, but also the team that maintains the API also maintains the web product, so some of the discoverability benefits of Graph aren't as valuable.
Hacker News has a pretty well educated community, so it's not surprising that the general response seems to be that this was an obvious outcome. But this story is not unique to this woman. There are a huge number of people that seem to be in the same situation, and it's dismissive to just say that people should be more educated.
People aren't rational agents. They suck at making decisions about their long term well being. They're told that the best way to support their future is to go to university, so they take out a loan under the assumption that once they're finished, they'll earn so much that paying it off won't be an issue. And if you're not particularly financially literate, you might assume that this is fine since everyone else seems to be doing it. And you might also assume that they wouldn't lend you money that you couldn't repay.
The reality is there's an information asymmetry in favour of lenders. They know better than you how likely you are to repay your debt. And their incentives are structured to maximise their return, not clear your debt. So if the best way for them to make money is for you to not be able to pay off your debt, that's what they'll try to do. The harder it is for you to understand what you're getting into, the better for them. The less financial literacy you possess, the better for them.
I'm not arguing that the author shouldn't bear responsibility for her decisions. Of course people should understand the things that they agree to and meet their obligations. But there is a calibration problem when the pursuit of an education can lead to three decades of financial hardship.
By all accounts she was well educated; she was accepted to and attended a private university and then graduate school over seas. She also made poor financial decisions spanning a decade. I'm sure she would have rather not made those bad decisions, but it's probably safe to say she could not have made better decisions because.. She would have, but didn't.
So what's the solution here? Do people take a test to determine if they are allowed to make their own financial decisions? If they don't pass their parents or the government decides for them? Sure we can tweak the terms, put up special regulations for student loans, or increase education.. However if we accept that some people are incapable of making good financial decisions, potentially for their entire life, this problem will remain? Does this extend out past financial decisions? We could have the human equivalent of processor binning.
I messed up my credit when I was in my early 20s. I was lucky enough to find myself in a better situation in my early 30s.. I'm not convinced I have gotten much better at financial decisions or have just managed to out earn my natural spending habits. Maybe both.
Some countries have free (and good) education alternatives. Some countries also have student loans as a public service. Education is probably one of the most important things to preserve a democratic state, so you would think it is in the public interest.
Further, interest calculation is actually a differential equation. I wouldn’t expect half the graduating class to understand its wreckless power. What students need is a nice excel sheet they can “play” with. If I paid this I would be done paying with loans here etc.
We need to make video games where you have to take loans at the start and then later pay them off. If this mechanic became popular enough I would wager that a lot of people would have some form of intuitive understanding of these loans.
Roller Coaster Tycoon (1999) had a basic loan system where you'd start most scenarios off with a 10k loan, and every week of the month you'd be paying back some interest. RCT 2 had a more sophisticated system where the interest rate was displayed to the player, and it some parks it was fairly high, to where one had to carefully reason about their financial options.
You don't need to know any of that to understand a loan. That's somebody's math homework, not an actual financial transaction.
When you get a loan, they tell you the interest as annual percentage rate (APR). That annualized rate plugs right into the simple interest formula they teach you in high school math class. You just calculate each year one at a time, plugging in the amount you owe at the start of the year and you'll get how much is owed at the end of the year.
If you make payments or if the rate changes during the year, you can use the same formula to calculate what you owe at the time of change/payment, and continue on from there. Using the effective annualized rate for less than a year will give you an answer that's slightly off, but it will be very close.
You'd have a very difficult time using differential equations for a real loan. That question has the buyer making an infinite number of infinitesimally small car payments, because a monthly installment would make it a bad differential equations homework problem. The sensible way to solve most real-world problems is just to calculate the result iteratively using basic multiplication and addition.
I suppose? The above mentioned method is really inaccurate. Student interest is calculated daily.
Here is a top search result for calculating student loan interest. They suggest not to do a yearly approach like you suggest. It even mentions doing a daily compounded function. I added a [LEAP] where the author left the reader hanging.
---
To understand how compound interest works, let’s look at an example. Consider a Direct loan with a $10,000 balance and a 4.45% interest rate.
First, you figure your daily interest rate by dividing 4.45% by 365 to get 0.012%. On $10,000, that works out $1.20. That $1.20 is added to your loan balance, bringing it to $10,001.20. That’s your new balance, and when interest is compounded the following day, you’ll pay interest on that total amount.
[LEAP]
By the end of the year, you’re looking at paying $455.02 in interest, rather than the $445 you’d pay if your interest was compounded just once a year instead of daily.
That's not using the APR percentage, which would be 4.55% for that loan. Had they used that, they would have gotten the correct value.
> By the end of the year, you’re looking at paying $455.02 in interest, rather than the $445 you’d pay if your interest was compounded just once a year instead of daily.
They used the wrong percentage and got $445/year. That's off by $10/year. Still, it's close enough to use for yearly financial planning and for judging if the loan is worthwhile. It should be sufficient to prevent any surprises like the article author's.
A very basic thing to do here is to pay off your high interest loan first. Her payments seemed to have gone mostly to reducing the balance of the lower interest ones. She did manage to reduce her total balance by $26000 and that could have been used to eliminate the $24000 high interest loan (which would actually result in higher balance reduction overall as well since less money would have gone to paying interests). Is there some structural thing preventing her from paying off the high interest balance first or was she simply not aware of a better way?
Based on the screenshot, it seems like autopay was set up on the lower-interest loans but not on the highest-interest loan. It's hard to say for sure but it does seem possible that she missed the impact of this.
You forget that there are also ignorant people who just take the loan whatever the deal is regardless if what they do makes sense - it just "feels" right for them. Then when the time comes to pay it back, they'll just try to moan it away. If there is enough people with such attitude so that it could be a good number of voters, there will be a politician willing to climb on it and force companies one way or another to waive the loans.
Ultimately people should be taught to take responsibility and not that ignorance pays off.
You act like all of these kids (and that’s what they are when taking loans, kids) have a support structure and education that’s taught them how to make good long term financial choices. Not everyone has good parents who taught them finances, never mind long term life planning.
No, but they all went to college, so they should have learned calculus, and derivatives. Even a debt that high should be payable with sweat and some deferral of immediate enjoyment, a situation that would have become obvious with just a little bit of math.
> No, but they all went to college, so they should have learned calculus, and derivatives.
I've been out of school for ten years, and haven't used calculus in about twelve. How exactly do you think knowing calculus would have helped here? Be careful assuming everyone learned the subject as you did and knows how/when to apply it to various situations.
Personally, I learned about interest rates in middle school. I used that knowledge, combined with additional research on subsidized loans, to decide to take out loans. I also had the advantage of learning the downsides of debt collection from my brother's mistakes.
Not everyone is a rational economic actor. Children/young adults ages 17-22 definitely aren't the most rational amongst us.
Seriously though it's obviously by design. Ever wondered why they don't teach financial responsibility in school? Give people incentive to work as much as they can to keep economy rolling. Capitalism at it's finest.
You forget that repaying a loan for something like the postmodern conveniences of a University Science Education may be the wrong thing to do, especially given that the Universities generally don't require vocational training as part of general education.
When people take the loan it's because they feel like they have to, and when they don't want to repay it, sometimes it's like, "No, look: if the people around me needed this so that I could live, something's wrong, and I don't want to continue collaborating with them."
The U.S.A. may also be experiencing an ongoing violent revolt against compulsory literacy in the high schools, so the problems don't really start with the loans and the college application process.
I vehemently disagree that this is an information asymmetry issue. That woman has been to a private university for some time when she signed that 9.5% loan contract. She must have had basic calculus in elementary school and calculating with fractions a few years later. Even her working-class father realized this was a bad idea.
A relative of mine is currently attending university who decided to blow a $50k college fund on TWO years of a four-year degree. I didn't even pay that much for four years (this was 10 years ago). A lot of the younger generation don't care because they don't have to pay anything now, so they'd rather go to a school they can brag to their friends about.
That isn't that expensive: $10k/year for tuition and books, $15k/year for housing/food/life expenses. Now if its actually $25k/year just for tuition, that's pretty expensive.
if you're going to a school worth bragging about (read: Ivy League) then those are actually the ones that provide pretty good financial aid to those less well off. If you don't meet the qualifications for financial aid but still find yourself unable to pay, perhaps you're parents are holding out, and/or living above their means.
The high interest loan was for her last year of school. She has indicated that there was no alternative. Of course it would have been better to arrange for all financing before she started school but that would have taken some foresight. I wouldn't blame her for taking the loan in the senior year. It is not a matter of simple calculus as you said -- it is strictly worse to not take the loan and quit school at that moment.
Add: Please consider the possibility that not knowing when you start school that you may need a high interest loan as a senior in order to finish school is an example of information asymmetry.
> She has indicated that there was no alternative.
Actually, she indicated that the alternatives were not attractive to her (especially the friendship thing is ravingly stupid).
> Of course it would have been better to arrange for all financing before she started school but that would have taken some foresight.
Yep. The ability to divide cost through four years, add a little bit for emergencies. This ain't rocket science.
Liferafts tend to cost a lot more when the flood is coming.
> Add: Please consider the possibility that not knowing when you start school that you may need a high interest loan as a senior in order to finish school is an example of information asymmetry.
I do not think anyone is served by abusing vocabulary to hide the true meaning you implied: it's stupidity and lack of planning, not information asymmetry.
This can be generalized to fairly large number of decisions one has to make in life ultimately a person making the decision will have to bear the consequences of their decisions. I think a general theme of people expecting someone else to bear the consequences for their poor decisions is a significant contributing factor to people getting into these situations.
It’s almost like 18 year olds don’t have a firm grasp on how to manage their future. Especially when they’ve been brainwashed to believe College is the only way they’ll have a future.
The Australian Prudential Regulation Authority has made it a condition of approving loans that the minimum scheduled payments end up paying off the loan in the indicated timeframe, and this applies to loans for real estate which is supposed to be a source of income.
Perhaps it is time to apply the same kinds of rules to loans for education, along with increasing the minimum income at which repayments are required to be made, and the maximum proportion of total income that the repayments are allowed to be.
In addition, require that student loans must be not-for-profit.
Perhaps even consider nationalising the student loan system and having repayments taken out of incomes at fixed low rates, so the incentive is for the state to improve wages?
The problem with the argument about information asymmetry in this case is that one of the loans was signed right after the financial crisis. Loans and topics about interests and all that were talked about in many places.
But I agree with the other commenter about excel sheets and playing around with numbers.
I've got a template that I think will solve this kind of cross-talk. Here it goes:
What follows is an institutional critique.
Some content goes here, preferably with citations.
This concludes the institutional critique.
Once the header and footer is in place, the reader is not allowed to make counterarguments based on anecdata or moral speculation about the personal responsibility of the institution's participants.
HN users are perfectly capable of making these distinctions. I'm sure if I post a paper about timing attacks that leverage subnormals, nobody would complain that HTML5 users need to better educate themselves on IEEE 754.
Now that I write that, I'm not so sure-- so please always use the template above when making an institutional critique.
To me, this seems like a possible case where people are rational agents, but they don't have comprehensive information. Selling a financial instrument that someone can't possibly understand is unethical, and should be illegal. My own rule of thumb is that the higher responsibility goes to the bigger guy.
You can buy a car without knowing anything about cars. You can buy a house without knowing anything about them. Do you think the seller is being unethical in these cases too? Particularly when you're buying the car from a manufacturer or the house from a large broker. What about selling a computer to somebody that is computer illiterate?
I agree that what the banks are doing is very likely unethical, but I think your generalization about the bigger guy having more responsibility doesn't always hold.
The other problem is that people will generally say that they understand even if they don't. Maybe a mandatory class on basic finance and economics would be a good idea.
Cars and houses are both heavily regulated for the exact reason of information asymmetry. Markets appear to have regulated computers, but I don't know if that can be generalized to other kinds of products.
I agree that schools should teach about personal finance. My son was assigned a paper to write on the payday loan business, and it was pretty eye-opening for him.
Why? google search of student loans problems turns up literally a ton of results on very reputable sites discussing these issues. If a person can not be bothered to make a simple google search before making a 100K decision I don't think the problem is the bank.
Oh. It sure isn't the bank's problem. You can't even default on a government backed student loan. The bank is incentivized for you to fail and rack up fees.
don't doubt that but starting salary of 20K with masters degree tells me the choice of degree was not optimized very well. There are many ways to get degree for close to free just takes a bit of effort but paying down 200K is def. significantly more effort.
Because most 18 year olds don’t think the entire financial system is designed to make them into financial slaves? Someone with authority says they are offering something good and smart for their situation so they believe them?
The banking institution which created, offered & services the financial instrument you’re describing has about 1 trillion times more data on the risks and the possible outcomes. They should absolutely have the responsibility when offering 5-6 figures to 18-year-olds.
Well than I have a bridge to sell you. You can not make a system where there is no personal consequences to making dumb decisions there is no "they" who will take a fall for you.
Then we should consider rewriting the laws which made a system where there is no consequence for lenders who make dumb decisions about who they lend to, and possibly consider consequences for the colleges they are basically colluding with?
The consequence for lender is not getting their loan back. You can remove special provisions related to student loans this will make loans less accessible and they will carry higher interest rates but it's a reasonable approach if people want to make this change.
I would argue the majority if not all of those websites didn’t exist for people who are struggling today. For new students, sure. But someone struggling in this situation didn’t have these resources in early 00’s.
This happened 10 years ago, and while I don’t doubt there were articles warning you about the dangers of student loans, it probably wasn’t as visible as it is today.
People aren't rational agents. They suck at making decisions about their long term well being
But, are legally adults, and that’s what that means.
These arguments about students not knowing what they’re doing has only one solution: raise the age of legal adulthood to 25. Which is not as unreasonable as it sounds; it was 30 in Ancient Greece.
From a historical perspective your reservation is totally fair. But I think the issue is a lot more complex than just looking at the impact automation has had in the past. Here are a few points worth mulling over:
1. Automation in the past has been good at increasing worker productivity, and making new avenues of work possible. This is true going forward too. But each new generation of technology isn't "something we've seen before", it's a new thing with new consequences. Technological development isn't cyclical, so estimating the impact a new technology will have on the impact previous technologies have had is a poor model. This isn't to say the consequences will be bad, just that they're hard to anticipate. For the most part, the historical perspective is probably right though.
2. Automation in the past has been very effective in improving worker productivity, but developments in AI and robotics are looking at ways to supplant workers (i.e. electric cars don't improve our ability to drive, it removes our need for drivers). While in the broad sense this trend is good, and people will over time shift into new industries, it is going to be disruptive. Timelines will have a big impact on the shock. New industries won't spring up over night.
3. The timeline for this level of automation is much shorter than previous automation trends. The shift in agriculture happened over generations. The shift caused by driverless cars will likely happen in less than a decade. Add to that the efficiency of market pressures we have today - once one business is able to shift entirely to an autonomous fleet and save money over their competitors, all their competitors will have to follow suite to remain competitive. Entire industries could be displaced, and those workers will need to move somewhere.
4. This is more hypothetical and longer term, but it gets at what I think is the general fear around automation. Imagine we develop the ability to automate any unskilled job (whether through broad automation improvements or development of an actual general-purpose automaton). The primary factor in whether a business would choose to employ that automaton over a human is cost. The automaton is a once-off fixed cost, whereas a human is an ongoing cost. Once the cost of the automation is lower than paying a salary, humans will no longer be employed in that role.
5. Following from this, if it's the unskilled jobs that get automated, where do those workers go? At this stage, even if automation is creating new lines of work, why wouldn't that work also be automated? Basically, once we automate unskilled work, we never need unskilled workers again. In order to find work they'll need to skill up, which takes time and money. And if it takes a year to train a worker to a level that they're a net benefit, why not invest that money instead into automating the skilled work too?
This is a complaint I've heard often about React, and usually it's by someone that's never actually tried it (myself included before I first used it). But it's a visceral response. Until you sit down and give it a go, it's hard to believe that we had the separation of concerns wrong. Separation of concerns refers to responsibilities, not languages.
If you're building a static website, sure, you probably don't need React - the old tools and techniques handle that use case well. But if you're building a webapp, something with complex, dynamic client-side behaviour, it doesn't make sense to pretend that CSS, HTML and JS aren't already heavily coupled by the nature of what you're building. React just embraces that idea, rather than pretending it doesn't exist.
The reality of modern apps is that JS is going to transform your HTML and CSS at runtime, and most of the bugs you'll end up tracking down will be related to it being transformed in ways you weren't expecting. React's component model and declarative rendering are far more effective at addressing this problem than any other tool I've tried.
Plus React still encourages the traditional separation:
- Model is props/state.
- View is render().
- Controller is everything else (lifecycle, handlers, etc.)
IMHO it's also best-practice to separate view from presentation using CSS modules for component-level styles, and sprinkling namespaced classes here and there so that the component can be styled externally using application-level CSS.
We didn't get the separation of concerns wrong. React is the same we've been doing for 15 years, but we finally understood we had to modularize and encapsulate it to encourage reusability and true separation of concerns.
I'm never going back to traditional code that violates the single-responsibility principle. I'm never going back to manual DOM mutation. Give me modular, namespaced, declarative HTML+CSS+JS and I'll stop using React.
>This is a complaint I've heard often about React, and usually it's by someone that's never actually tried it (myself included before I first used it). But it's a visceral response. Until you sit down and give it a go, it's hard to believe that we had the separation of concerns wrong.
We didn't. And React doesn't change that either. React components are not logic code, they are UI code, and that has always went with view concerns (loop this times, show this button or that button depending on state, etc).
In the Desktop GUI space, where they don't have our HTML madness, do you think their UI components are not using code? Buttons, drop-downs, etc are not appearing by magic, they are created by code that does things like: draw a line of x length and y color, then another perpendicular to that, etc, then loop and draw some stripes, etc. That's the case even in Smalltalk, where MVC was invented. That still matches with "separation of concerns" -- which is about not mixing your BUSINESS logic with your UI code, not about not having code in your UI rendering.
In fact, compared to the classical way (foreach and other kinds of template instructions embedded in template strings, from PHP's Twig to Angular) it's even cleaner, because even though JSX looks like HTML it's actually compiled to Javascript instructions it's not just some ad-hoc language hidden in template tags to be interpreted at runtime.
And separation of concerns also applies to UI elements (encapsulation, re-use, etc) something which "logic free" templates like Mustache and so also miss (or, well, make harder -- of course if you try hard enough you can always fit a square peg in a round hole).
I can't comprehend the very idea of "template languages". Especially in PHP, because PHP itself is a decent template language by design. But even outside - they always evolve the same. They start as a "lightweight" way to avoid putting code into view templates, but then they slowly accrue conditionals, loops, local variables, half-assed tools for defining functions, and before you know, your "no code allowed" template language becomes a Turing-complete and pretty crappy replication of PHP.
And all of that is orthogonal to the main insanity of this whole era - stitching HTML from strings. HTML is a structured tree format, and should be built out as a tree. Gluing strings together is the source of oh so many errors and security vulnerabilities...
And after you replicated PHP you come to the conclusion the templating language is as slow as hell. So you think: maybe we would need a compiler so we can cache the templates.
The question ofcourse is: why would people rather use:
And I think this goes deep. People are looking for more human ways to express themselves. And PHP is not a very beautiful language. So maybe my first example looks more 'human' than the PHP example.
Which at this point just differs in delimiters (<? and ?> instead of { and }) from the template language.
I don't have an opinion on this "more human way" to express oneself, but it seems that it would connect this case with the reason people seem to prefer curly braces to parenthesis in code too.
Which is, IMO, the main problem with using PHP (or any other from of plain string concatenation) as a templating language. Escaping everything (and security in general) should be the default, not something that you have to opt into at every turn.
I've never understood why people use templating engines in PHP. I've been an on again off again user of PHP for atleast 7 years now, and I've never understood it for exactly the reasons you outlined.
I've worked some with both WinForms and WPF, and so far I kinda like XAML. And is you're not only working in the windows world, I hear there's a similar-in-spirit JavaScript/HTML framework being used for "new hotness" style applications. Called "electron" or something like that I think?
Electron is that thing that bundles the whole web browser with your application so that you can write your usual web code and have it look like a desktop app.
Completely agreed... I've been building web based apps for over two decades now. React is the first framework that feels "right"... there are some things that could be better, It's so much better than what came before. Angular brought me so many WTF moments, I can't even begin to mention them all, even ng2+. With React there's been a handful, usually with a useful error that made sense.
So much effort has been done with React to work with the broader JS community and its' direction as opposed to against it. ES6 class syntax, simple render function components, modules. React doesn't need much to get started, and it's unprescripted enough that just a few tools can round it out, with heavier and lighter options.
I don't want to go back, and frankly, I'd rather have JSX in my JS than go back to weird template DSLs ever again.
> Until you sit down and give it a go, it's hard to believe that we had the separation of concerns wrong.
Well, we had - the whole "separate content from presentation" thing was a cargo cult. Before the recent wave of JS frameworks, the standard website was littered with tons of div elements, almost all of which had zero semantic meaning, and existed only as CSS hooks and/or a hipster replacement for tables. And it was like nobody stopped to ask if all those divs aren't breaking the "separation of concerns" rule - or even if the rule made sense in the first place (it didn't; "presentation" often delivers as much information as "content" itself).
I don't know of any other industry so blinded by fads than web development.
I always thought it was a little silly to religiously persecute script-tags at the bottom of an html page for single-use event hooks and listeners and initialization logic. Instead I was told best practices were to split that one-off code out into another file, bundle it up with a bunch of other unrelated garbage, minify it, and link the whole kit and kaboodle in.
Meanwhile, when you need to go edit the logic operating on some element later, you end up grepping through your code base for ids, classnames, element types, whatever, trying to figure out where that bit of code that operates on that element got to, often several directories in the file structure away from the markup.
Well, yeah. Forgive me, because I never know, here, if I am talking to my grand-son or my grand-pa, but "Separation of concerns", as an idea, came up when we thought that HTML/JS/CSS was about describing web-sites, for, for example, the NYT vs the WSJ, not for an applet or Swing replacement.
Separating content (including, maybe, semantics too) from presentation (branding, look&feel) makes sense when you are talking about web-pages. I don't even know how the idea transmogrified into a point-of-contention on SPAs.
It's quite funny when you think about it: "Look, Ma! I can build a fully functioning GUI out of type-setting elements and sticks!"
We could extrapolate this trajectory and take a page out of lisp history. Why don't we just let a "web page" be an s-expression delivered by http and run within a sandbox?
If you look at what the racket team has done for their documentation system "scribble", it is pretty clear that we can engineer whatever modularity we require for the purpose at hand given that generality.
That's just silly. Ultimately every tool outputs a 'string' that gets sent to the browser.
What matters is how this happens, and there's a huge difference between React's approach and '<div class="whoops"><?php echo $some_unescaped_dangerous_thing ?></div>'
The sanctioned way forward for React is Flow. It's not as comprehensive as TypeScript, but there's no compilation required - Flow annotations just get stripped out. As of a couple of weeks ago it is part of create-react-app.
Too bad flow doesn't work as well as typescript in practice. It has way more bugs, is not as tested.
It was very promising at first but typescript now has caught up with Flow best design decision: noImplicitAny, strictNullChecks.
Also, check on the "try typescript" website: typescript's JS output is almost left untouched. it's effectively a replacement for babel, if you only care for ES2015 stuff, and not some of the more recent stage 0 / stage 1 stuff.
this. tried flow, but it's too 'smart' for my iMac to handle. Flow reads all JS files without problems - which killed my iMac after using 6>gb ram. a partial solution was to manually set ignore on some node_modules packages. but still, really slow experience with atom/subl/etc.
Compared to this, typescript is actually dumb enough to require ts definition files to actually parse non-ts (js) files.
1. Senior people leaving (as has been said by pretty much everyone else in this thread).
2. Not having a clearly defined problem to solve, or a well understood target audience.
3. Not knowing who the competition are, or just dismissing them as "not being as amazing as us."
4. Little or no customer research - if you hear the phrase "customers don't know what they want" and it's not immediately followed by "so we need to do research and find out" - run.
5. Building solutions that don't really map back to problems. This can manifest in a lot of ways, but the most common ones I've seen: projects constantly changing in priority (entire projects materialise and become urgent overnight), features that are arbitrarily demanded, or in an over-emphasis on polish and minutia.
6. Departments not collaborating, things getting thrown over the fence. Workflows that move in the wrong direction.
7. Lack of autonomy - a handful of people make all of the decisions.
8. Micromanagement. People tend to micromanage when things aren't going well, which tends to make them worse. It's a downward spiral.
9. Being afraid to talk to management about problems; being chastised for suggesting ways to improve things.
10. When mistakes are made, focusing on blame rather than resolution and prevention.
I'm very familiar with #8. I worked for a company that was being super picky with its term sheets when looking for investment, but then suddenly the credit crunch happened and all our term sheets were withdrawn. Problem was, we were spending as if we'd already had an extra $15m in the bank, so we had to start cutting back.
I'd had a habit of coming in around 10 AM and staying most of the day and part of the late afternoon/evening; typical startup kind of 'go get lunch then come back and crank out some code' behaviour, while most of the rest of the dev team came in between 11 and 1. This includes one of our best developers, who, without downtime, ported an entire product from PHP to Rails on his own time over the weekend because the code was unmanageable and he wanted to be able to iterate faster.
Suddenly, after most of the most senior (and most expensive) people have left, the CEO decides that everyone needs to be in the office at 9 AM, you know, so we can communicate. Sure, okay. So people start coming in at 9 AM. They're tired, they haven't had breakfast, they only got 5 hours of sleep, but boss wants people filling seats so we fill them. I start getting phone calls at 9:03 if my bus is running late, because my buffer time was usually taken up by being in such a rush that I forgot my wallet.
So every day, everyone's tired, everyone's frustrated, and everyone's leaving after they've put their 8 hours in. My start date, when my options were priced, was the highest price the shares had ever traded at. But I was still one of the most well-paid engineers so I stayed until I got 'downsized' and took a month off.
Last I heard, the CEO was getting sued by the board for treating that company as a source of resources for his other company (like flights back to his other company's office, or my tech support to get his people up and running).
#10 struck me. I'm doing work for one guy that seems somewhat litigious and I'm afraid it might bring the startup down. There's no such thing as a solid contract with a bad person.
All great points. In my experience I have seen revenue losses followed by products/solutions which do map to the main objective of the company but in reality is scraping the bottom of the barrel. Example having billing of $1 million MRR but then releasing products with $15-20k MRR. So essentially the management is out of ideas on how to make up the revenue losses.
This is something that tripped me up when I first started learning Redux too, and it would be great if there were more articles about what to do with the bits that don't really fit nicely into the model.
My personal take is that the Redux state tree is for managing state that other components care about, i.e. if this changes, does something outside of this need to know? In the form example, there are few cases where we care about what is being typed as it is being typed (maybe autocomplete). We generally only care about the complete input. This could even be taken to the next level and we could say we only really care about the contents of a form once it has been submitted.
To think about it another way,: what state would we like to keep if the page was refreshed? Many UI elements may contain state we don't really care about outside of the component, such as drop-down menus, accordions, etc. There are things which constitute global state, and there are things that really are just local state. Why make them global?
Ultimately, the goal of Redux is to make reasoning about the state of an application easier, and to encourage better architecture. If pushing certain bits of state into the tree makes this harder, there's no reason to try to force it to fit the pattern.
I'm sure there are good arguments for why everything should be in the global state, but I just haven't found it to be practically beneficial.
It's usually people. Sometimes it's opportunity. But it's usually people.
I've ended up with a lot of thoughts on the topic, but I'm not sure how best to convey them, so I'm doing to rant in dot points:
- People rarely leave because of technical decisions. Most people are appeased when you can explain the rationale, even if they disagree
- Good leaders make or break an organisation. They inspire people, they give them a cause to rally behind. A lack of good leaders will kill culture within a year
- Good leaders own problems and will find a way to solve them, they won't accept the status quo
- Bad leaders will tell you why a problem is not their fault, and do nothing to fix it
- Good leaders need good leaders - it starts at the top. A good CEO will change your worldview
- Good leaders-of-leaders know everything is kind of fucked, and appreciate leaders who are actually trying to improve things, without expecting they're going to get everything right
- Leaders need to really believe in their cause. People know when you're faking it
- Culture is not a by-product. It's the product. You work hard to create a good culture, and it can disappear very quickly. Building good culture is how you build good teams. You can't work around a bad culture
- Most of being a good leader is just turning up. Be there for your people, listen to them, try to make their lives better. Make time for them. Show them you care
- Regardless of all of this, people will leave. Sometimes because the company isn't a good fit, sometimes because they're at a different point in their career. Attrition is healthy, you just need to keep a pulse on whether it's happening for unhealthy reasons
In summary: yes, it's pretty much always people. Building software is easy. Building a healthy work environment is hard. Most people focus on the easy problem.