I'm waiting for the day where 3D printers become so powerful that I only need a minimal set of these "physical" DIY skills to build random physical objects.
Anybody know of a printer that can get me very close to this goal?
>but up close the details of say, managing state with hooks in React, is very different from managing state with services and RxJS observables in Angular.
I would say learning the detailed difference when needed for the project is in fact extremely trivial. The wrong kind of learning is thinking that you're improving your skills by memorizing and learning all of these details even when it is not required by your current project.
I would say max it takes about 2 weeks to a month for a developer to get good with react. It's not even a big deal if you think about it, but hiring managers still look for "relevant experience."
Don't learn the details unless it's relevant to the project. To improve your overall skills as a developer: Learn the fundamentals.
Though I have noticed one thing. Many recruiters and even technical hiring managers are buzzword driven. Buzzwords are often related to details so to pad your resume you have to learn the details. Ultimately though, if you end up never touching that detail or that detail changes then you wasted your time learning it.
Learn the fundamentals because the fundamentals never change.
Honestly you're the kind of developer that the OP is talking about, but then again most developers are like that.
>But if a candidate is motivated to take a job because they get to use shiny new technology, i would suggest that they are not, in fact, a good candidate.
I would argue that this attitude often exists at the corporate level as well.
Most companies I've worked exist in a perpetual state of migration from monolith to Micro services. Basically the overall architecture remains static in the sense that it's always a giant monolith sitting in the center with some satellite services surrounding it.
The migration to microservices and kubernetes is 99% buzzword driven and rarely has nothing to do with whether or not the product will benefit from the migration. The weirdest part about it is that it's many times a never ending thing initiative. It's very rare for a company to actually arrive to a point where every component of their system is split out into small pieces. It usually just stays permanently as some services surrounding a monolith despite all the talk.
When entire companies are like this it's usually a sign that the entire company is weak. My experience has been that many companies have this attitude and many programmers share it.
If all/most programmers share this general attitude then I wouldn't call these "new technology chasers" bad as most people are like this.
>In my experience, magpieism is associated with weaker programmers; not the very worst, but second quartile, say - people who get very engaged with superficial details, but don't think about deeper things.
I may be biased because I know I talk a lot. But my experience has actually shown that this is not true.
People who don't know a lot of things tend to stay silent. This strategy works consistently to allow many people to hide extraordinary gaps in knowledge. It's very common and the strategy works.
When you see a person not talking too much... human bias tends to err on the fact that he's just not a talker or he may be deep in thought. Never do you think that a person isn't talking because he doesn't know anything. To be not biased is to consider all the possibilities and basically 90% of people just skip over the thought that the person isn't talking because he doesn't know anything.
Now for a talker, the bias goes in the other direction because a talker has an incredibly higher chance of saying something you disagree with or is flat out wrong. This chance is higher EVEN when the talker is more knowledgeable than the non-talker simply because the talker places himself on the pedestal of judgement every time he opens his mouth while the non-talker avoids it.
If you know a non-talker who may or may not have kept his trap shut after you explained something to him, really the only way to confirm whether he knows what you're talking about is to ask him confirmation questions after you talked to him. If you don't do this, likely he'll just google the info later and pretend that he always was on top of everything.
You have to really watch out for this bias. Even as a talker I tended to bias towards thinking that the quiet nice guy was more intelligent. The reality is, "magpieism" has no correlation to how good or bad someone is... if someone talks a lot they could go either way, it's just that because they talk a lot, you have a ton of info on how good they are based off of what they say... while the non-talker you have no info and your judgement is (unknowingly to you) influenced by your biased optimistic assumptions.
If someone is quiet there is a higher chance that he's quiet because he's totally lost. And if he's quiet often... then there's a higher chance that he's totally lost all the time.
This stuff all comes from China originally. I'm Chinese so I know.
It's because Chinese characters use to be written with brushes and with brushes the stroke order of the lines is very important for legibility and beauty. See the pictures in the link, you'll understand: https://www.google.com/search?q=chinese+calligraphy&rlz=1C5C...
Just imagine what those characters will look like if you did strokes out of order...
This stroke order carried over to pen and pencil and also to japan after they adopted Chinese characters as Kanji and invented their own unique scripts called hiragana and katakana.
Even with a pencil, stroke order is still very important to Chinese characters, it's kind of like an accent in your writing. People can sense something is off with your writing if you wrote strokes out of order. It's still legible and can even be neat but people can sense something off with stroke order.
Japanese people are just taking stroke order and applying it to English.
>Good teams don't blame individuals. You can praise individuals, but you take blame as a team.
This is a form of illusion. A cover up for what is essentially in reality a mistake made not only by the team but by the individual as well. To mask part of the truth and lay only the blame on the team is an effective form of not hurting someones feelings but also an effective form of avoiding the full reality.
Do people not see how illogical it is to blame the team but only praise individuals? The precedence being set here is that: People succeed as individuals but fail as teams.
The harder ideal to strive for is that both the team and the individual take the blame, but it's harder because people are prideful stubborn and easily hurt.
If you make a mistake step up and admit your mistake. Don't hide in the corner and expect the team to change all their processes to account for your mistake. Yes the team should do this, but yes you should stand up as an individual and do things yourself as well.
There are times when you must blame an individual. Let's say a team member repeatedly pushes bad and buggy code to production. Is it the teams fault or the individuals fault when such actions are repeated? Does it lay on the team or the team member to make sure buggy/bad code doesn't go into production?
The line is blurry here and I feel it is ultimately the wrong stance to say absolutely good teams don't blame individuals. Good teams and good people take responsibility so there is no need to dish out blame.
What happens when the person who spilled coffee all over the on premise servers doesn't take the blame? The team sees this and decides to blame nobody. Is this a good team? No.
The good team member volunteers and states publicly that the fault is his own. The good team agrees with this stance and also says that the fault is with the team as well and both the individual and the team take steps so that this mistake cannot happen again.
The reason the blame is taken as a team is so that methods are put in place to prevent those problems in the future. If it were simply a blame game those issues would not be resolved. Humans do not operate on pure reason, and if you decide to do the blame game they will rarely resolve the underlying issue that caused the problem in the first place. The blame game is a stupid game, and as we know playing stupid games wins stupid prizes.
It isn't about eliminating recurring problems, it's having the highest chance of reduction. If someone continually performs poorly then thats management's responsibility to replace them.
It's also that we (the team) failed to put steps in place to prevent the problem. The person who pushed the button that took down prod is only the last person who made a mistake. Plenty of mistakes were made before, otherwise their mistake would've been a non-issue.
If your system can't tolerate one person's mistake, it's not robust.
None of this means you can't praise a whole team (you should! The original statement just said you CAN praise individuals), or discipline team members who regularly show poor judgement.
>or discipline team members who regularly show poor judgement.
Isn't this contradictory with the original premise? If you discipline an individual you are blaming the individual.
You're saying you can praise individuals and you can discipline individuals and you must also follow this: "Good teams don't blame individuals. You can praise individuals, but you take blame as a team."
Do you not see the contradiction? I'm literally getting voted down because of slightly miffed feelings.
Despite all of this the logical correctness of my statement stands and you have inadvertently agreed with every aspect of my statement.
People are down-voting because they disagree. While it's not something I agree with, it's officially sanctioned on HN.
If I'm continually pushing buggy code, that's something that I'm going to be personally held accountable for. Blamed if you will. That's because I'm the only one involved. My team isn't constantly writing buggy code, I am.
If I push buggy code into production and take down the site then the team is to blame. Why is our process setup such that I can do so. EVERYONE, even the best programmers will make mistakes, and if the process allows those mistakes through to production then the TEAM has failed to build a suitably robust process, not the person who happened to write a bug, because every human being will be that person one day.
Your taking a once sentence philosophy about how to deal with technical incidents and treating it like we're advocating it as a universal and moral absolute. No one is claiming that if I throw a rock through someone's windshield my whole team should be arrested. What we are saying is that is I make a slip up and write a bug that takes down DDG, I shouldn't be held accountable for taking down DDG. If there's a larger pattern of poor decision making I'll be help accountable for THAT, but it's completely 100% separate from the outcome of knocking production offline.
>People are down-voting because they disagree. While it's not something I agree with, it's officially sanctioned on HN.
I think a lot of vote downs are emotional and reactionary rather than genuine disagreement. I think that's the majority. I can't fault people for this as it's part of human nature but I don't think this type of voting is ever officially sanctioned by HN.
>If I push buggy code into production and take down the site then the team is to blame.
And you are not? I propose that you and the team should take the blame. People make mistakes but all the time and they shouldn't be singled out for it, but I don't think it's good etiquette for the team member who made the mistake not to own up to the mistake either.
>Your taking a once sentence philosophy about how to deal with technical incidents and treating it like we're advocating it as a universal and moral absolute
It's a one sentence philosophy that doesn't hold any logic in my opinion. I'm not saying anything is morally absolute here, I'm trying to say that the quotation doesn't even hold up in even the most basic situation.
It's elegantly written, no doubt, but I think that elegance is deceptive and that's why I wanted to say something. The real world in my opinion is nowhere even remotely close to that philosophy. I would argue that philosophy is just a surface level special case. In the real world people get blamed and fired all the time.
>Also, just a bit of friendly Internet advice, this isn't the best way to interface with people:
Well I'm getting massive vote downs and the original poster literally called what I'm stating as initializing stupid blame games to win the stupid prize. Kind of rude and insulting. I think it's reasonable to say that my reaction is reasonable given the attack.
It's not exactly the real world on HN either as people are harsher than normal, ruder and less receptive of differing opinions.
I would say that Giving people a piece of "friendly advice on interfacing with people" won't exactly win you any friends either. If you teach people things using that methodology you will get a retaliatory response whether it's on the internet or the real world as the tone is a bit domineering and elitist.
>Blame is for incidents. Discipline is for patterns.
This doesn't make sense to me. I can't blame people for patterns? I can't discipline people for incidents?
The sort of short and terse elegant expressiveness of the phrase ultimately hides a statement that makes no logical sense. Typically someone is blamed first before he is disciplined. Both go hand in hand.
Either way, you're probably just trying to say that let the team get blamed but if you see patterns then blame the individual. Not as elegant but no linguistic tricks that decorate ultimately illogical statements to appear as philosophies of life.
> If it were simply a blame game those issues would not be resolved. Humans do not operate on pure reason, and if you decide to do the blame game they will rarely resolve the underlying issue that caused the problem in the first place. The blame game is a stupid game, and as we know playing stupid games wins stupid prizes.
I never said play the blame game. I never said the team must not take the blame. Please don't put words into my mouth.
I literally said it's the teams fault and the individuals fault. Both parties must take responsibility.
Take it this way, if a single team member repeatedly makes mistakes then is it the teams job to put methods in place just for that team member? Or is it the teams job to help that team member as an individual?
The blame game is a stupid game so don't play a blame game. Take responsibility both as a team AND as an individual. The team taking the blame exclusively is AVOIDING individual responsibility. It is not a sign of a healthy team.
I am essentially saying the solution is not so clear cut. The team can't always take the blame just to "avoid a blame game." The reality of the universe is that problems aren't always team level problems, that problems at the individual level exist as well.
To exclusively avoid addressing problems at the individual level is a stupid and delusional endeavor and you also win the stupid prize for ignoring reality.
>If someone continually performs poorly then thats management's responsibility to replace them.
This is called blaming an individual then firing him. It entirely contradicts your main argument. I didn't even go there yet, I advocated blaming the individual than helping him improve as a team. You immediately cut his head off and let management do the dirty work.
There's a benefit in the cardinality during type checking when you use an external type checker. Strings have infinite possibilities an enum type is strictly defined.
Also I'm sure with reflection you can actually implement a simple enum pattern matching function on an enum that is exhaustive and throws a runtime error immediately if every possible enum case is not covered.
I'm not following this thread at all. What "exhaustive search" are you guys referring to? In a switch/case block?
Python doesn't have that, unless I missed it while living under a rock.
I.e. if you're working with python Enums, you type-check for that Enum, and then the IDE does it all for you. If you want to "check" for a specific enum, then you cast to it and the runtime Enum implementation does that checking for you by throwing an error if you try create that Enum with an invalid string value. And if you've got a raw string, before it goes too-far into your code base, you cast it into the specific Enum type, and when serializing you serialize it to the string value. Easy-peasy.
AFAIK, they're talking about languages like Rust, or C/C++ with `-Wswitch` (also implied by `-Werror`, which will warn you if you haven't handled all enum cases in a match/switch statement.
as someone else in this thread pointed out [0], it's possible with MyPy when using if/elif/else, or if you did it with a dictionary lookup, you could write a very simple test that checks that the set of enum values is equal to the dictionary key members. I've done this before, it works well [1].
In some typed/compiled languages, a substantial benefit of using enums is that it provides some way to automatically determine if you've handled every eventuality. That's super not a part of normal Python as you've mentioned.
The second part of crimsonalucard1's post was referring to somehow hacking in that type of functionality into Python.
I think you could somehow do that with nested context managers - something like:
with EnumChecker(e) as checker:
with checker(enum_type.A):
# do thing
with checker(enum_type.B):
# do thing
...
Where `e` is an instance of `enum_type`, and the inner context managers acting as if/case statements, then you could on any single execution of the code block (so you only need a single test case) ensure that you covered all states.
imagine an enum called bool with two values: True and False.
switch(value: bool):
case True:
// do something
case False:
// do something else
end
The above code is exhaustive in the sense that the logic covers all possible values of the enum type. The "exhaustive matching" we're talking about is similar to a pre runtime type check.
So imagine where someone writes this code:
switch(value):
case True:
// do something
end
The user did not handle the False case in his logic. Exhaustive pattern matching will catch this before the program runs and throw an error similar to a syntax or type check error. It will say that your switch function needs to handle all possible cases of bool. It needs to handle True AND False not just True.
The power of this basically allows you to encode safety of if else logic into a type and pass that safety throughout your program. It's pretty incredible, so much so that whenever this feature is part of a language I have stopped using if else statements almost completely.
Keep in mind the power of pattern matching extends beyond just exhaustive enums. An int is a form of enum as well:
switch(value: int):
case 0:
// do something
case >0:
// do something else
end
with powerful pattern matching features the compiler should immediately let you know that your switch statement did not handle the case "<0".
People, by nature, have one dimensional views about a world that is in actuality multi-dimensional and highly complex.
Humans evolved this way in order to navigate the complexity of the world as quick decisions and judgements aid more in survival than best decisions made at the expense of haste.
It takes a lot of effort and luck to exit our biases and see that even a murderer, child molester, pedophile, rapist, racist, dictator etc. have multiple dimensions.
Not condoning crimes, but honestly I can relate to how someone like Dennis Rodman can chill with Kim Jong Il or even Hitler if he was still alive, but I'm not sure how people in general will react to what I just said and how far above their own biases they can pull themselves.
I guess we'll see with the karma, I used some extreme vocabulary in the sentences above. I think if the OP used the word "Unabomber" instead of "Kaczynski" people would be less forgiving as my initial reaction to his post was positive simply because I didn't recall who "Kaczynski" was...
re garding the CIA comment, there are core values that are exactly opposite of what was stated.
Candor is a fundamental quality for any CIA associate
you should be upfront and open about what you want and expect.
Recognition of the potential for positive contribution by any and all people, some volunteer this willingly, some must be managed into such a contribution or placed in a context that creates positive results from seemingly negative actions.
Can dor is a stark contrast to skills it takes to be successful in the field of espionage and deception.
A person who is truly honest and open will fail to be a spy as he will reveal the true nature of his intentions way too easily. To succeed against foreign opposition you must be deceptive. To be deceptive means you cannot have candor. If the CIA requires candor as a fundamental quality of any associate then that means they require associates to have qualities that set them up for total failure.
Instead the unstated but obvious conclusion that can support two seemingly contrasting requirements to be a successful agent is this:
What the CIA truly values are people who are good at deceiving the organization itself into thinking they are honest and have candor.
Honestly, I don't think anything I said in this post is true.
That's true EBC is quite the metropolitan hike. I ended up traveling solo in the Indian Himalayas, through Uttarakhand, Himachal, and Ladakh. It's far less developed. I spent a few days without seeing a single human. This was also back in 2013, so it may have changed by now.
But more generally, I'm often out of the service area when I'm backpacking here in the US, so no internet for a week or more. I suppose by backpacking I strictly mean multi-day wilderness camping on remote trails, and not well-established treks between huts or campgrounds.
Anybody know of a printer that can get me very close to this goal?