crimsonalucard1

>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.

>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.

> 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.

>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.

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".

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.

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.

Glad you didn't get voted down.

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...

I backpacked through the Himalayas for 2 weeks to Everest base camp.

I had internet access throughout the whole trip, so I'd say it depends on where you're backpacking.

1990s as well was mostly internet free for an average person. It was probably towards the end of the 1990s when people started getting wired.

I remember when I was a kid, before the internet became ubiquitous, sometimes I would decide to re-read a book I already read from scratch.

Nowadays I can't even finish a book.

I'm not sure how relate-able that experience is because I was an only child and I was alone a lot. I'm sure most people (aka people with siblings) never get bored enough to re-read a book from scratch.

I guess I would say the good thing about the internet is that there's now a never ending stream of things to learn. The bad thing is that now I have lack of focus.

Yeah but the title Application Engineer sounds like Dev Ops or backend engineer or front end engineer.

Never is it mentioned that this is a position that is not a software engineer and is paid less than a software engineer.

Like do I need to ask whether a backend engineer is a software engineer? If not why do I need to ask this about an Application Engineer?

This role is where google puts most of their contractors.

There is nothing wrong with this. I am saying what is wrong is that people aren't made aware that this is what the position entails. You are being hired on as a lower class engineer.

I've had friends hired without being aware of this fact. Literally great software engineers at other companies with google fully aware of their previous title than suddenly unknowingly delegated to a lower class position with google not elucidating the difference.

It's like a software engineer applying for a software technician job. And you as the hiring manager not mentioning anything because you know the person applying isn't yet fully aware of the difference. These roles are literally targetting people who have software engineer in their titles but can't make the cut of the normal google interview.

It should be made clear that there is a difference between a technician and an engineer... just like it needs to be made clear that an application engineer is not a software engineer at google.

Also I would argue that the expectations are generally the same. You are spending your days programming there's really no difference.

Additionally it's an elitist attitude on googles part. Basically their saying that everyone who is normally considered a software engineer at other places aren't qualified to be software engineers at google. The only people considered to be software engineers are the people who pass that interview which is less than 1% of all people who apply. So they funnel these people into a lower caste that can never move on to be a software engineer EVEN when performance proves otherwise.

Get this, I just found out Google hires for a role called "Application Engineer" which is a role where you program but are lower class and lowered paid than regular "software engineers."

Google might not agree with the "lower class" part but the fact that for an application engineer to switch roles to software engineering within google requires them to go through a harder interview process indicates a deliberate caste based ranking structure that limits growth based off of your ability to pass an algorithm interview.

I actually believe it's 100% within google's rights to do something like this, but I think it's very bad that they disguise this ranking with the role name. I know people who didn't realize what they were getting into until they joined google.

Seriously, just name the role for what it is: High IQ Software Engineers vs. Average IQ Software Engineers because that's essentially what they're interviewing for.

Like someone else mentioned that's not a fair representation.

Warren is paid in growth of his net worth.

Yeah logging is like a bike. Generally worse than the car but good for you in terms of exercising your brain.

Your input caused me to google a video about this:

https://www.youtube.com/watch?v=kswiDQ2aAKA

Very intereting!

Is there an element or compound in the universe that will remain a gas at 0K? Does everything become solid at that temp?

There really is no logical argument. People have their preferences for a bike or a car but the car is faster than the bike just like how the debugger is generally better then printing. There is very little logical argument for the alternative.

Taking a snapshot of program state using log is isomorphic to freezing the program at that same state. The difference is that with the debugger you have the option to step into the next state or increase your resolution and look at state within a lower level module/function. With the debugger you have access to ALL state at the point where you froze it, not just statements you happened to log.

With logs, the way you debug is you log some state, reset the program with more logs and iterate until you find an issue. With a debugger you freeze the program examine all the state .... advance the program however far you want.... then the issue is found (unless you advanced the state too far ... but with logging the state ALWAYS advances too far until the end of execution, so with logging you always need to reset).

Logically, logging is just debugging with less features so people who prefer logging just in general don't want to use the extra features. Additionally logging has the added downside of constantly polluting your pristine code with your log annotations which you have to remove later (can introduce more bugs). While debugging with console PDB has the same effect, a GUI largely alleviates this problem.

The only argument for logging/printing is that you can use logging to debug an application in production.

I guess choosing when or how a program deallocates is important in a language that's close to the metal.

Rust tries to be zero cost while providing abstractions that make it seemingly a high level language but ultimately things like this show that it's not exactly zero cost because abstractions can incur hidden penalties. There needs to be some internal syntax that allows a rust user to explicitly control deallocation when needed.

If I started reading code where people would randomly move a value into another thread and essentially do nothing I would be extremely confused. Any language that begins to rely on "trick" or "hacks" as standard patterns exposes a design flaw.

Maybe if rust provided special syntax that a function can be decorated with so that it does deallocation in another thread automatically? Or maybe an internal function called drop_async...? This would make this pattern an explicit part of the language rather than a strange hack/trick.

Does there exist a solution that does what kubernetes does but without the complexity?

If such a tool does not exist do any of you feel that the creation of such a tool is within the realm of possibility?

I would imagine all these knobs could have default configurations that 99% of all users would be okay with and that the knob should only be exposed in a small amount of cases.

I've been to Tijuana a lot for very very short trips. How safe is it to live there and what's it like?

Because it's like using a while loop to print out each character in a string when you can just do print to print the entire string.

I don't want to worry about external methods modifying state, I don't want to deal with constructors, I don't want to deal with instantiating state or modifying state before I call my function.

My function just takes a state and returns a new state. Simple.

Well I mean would you rather have this:

    method(state){
        return doSomething(state)
    }

Or this:

   class A:
       otherThingThatMutatesState1()
       otherThingThatMutatesState2()
       otherThingThatMutatesState3()

       method(){
          this.state += 1 // or some other mutation
       }

Less complexity to deal with. No need to worry about external scope or external methods mutating properties on objects. No need to think about constructors or anything else. No need to worry about inherited properties. No need to instantiate the object before executing the method.

All you need to do is define a function and call it.

Literally, again I urge you to take a look at the following example, it's waay more simple than OOP:

https://news.ycombinator.com/item?id=23338700

I would argue that it is actually waaay more awkward to use objects for this. See my example code here:

https://news.ycombinator.com/item?id=23338700

You will see that it is far more concise and intuitive to do it with a function.

You still hit the same issue and you can still solve it the same way by converting that class with saved state into just a function.

Below are two short examples of two different ways to do this:

   type Node = Null | {value: int, left: Node, right: Node} 
   //a Node is NULL or a value that is an int with left and right nodes

   //procedural with mutation, saved state is placed in parameter: found
   def find_n_and_print_all_DFS (node: Node, search_value: int, &found: Node) -> Void:
      if node == Null:
         return
      else:
         print(node.value)
         *found = node.value == search_value ? node : Null
         find_n_and_print_all_DFS(node.left)
         find_n_and_print_all_DFS(node.right)


   //functional, no mutation, saved state is returned
   def find_n_and_print_all_DFS (node: Node, search_value: int, found: Node = Null) -> Node:
      if node == Null:
         return found
      else:
         print(node.value)
         found = node.value == search_value ? node : Null
         left = find_n_and_print_all_DFS(node.left, found)
         right = find_n_and_print_all_DFS(node.right, found)
         return left != Null ? left : right

I would argue that if I used classes the code would be way harder to read and much more verbose.

You can essentially use tail recursion on that DFS and pass in some accumulator as a parameter into your DFS or whatever. That accumulator can be some pointer representing some saved state or anything you want. There is still no need to group everything together into an Object.

It's a bit trickier but in the second example you can see that you don't even need to mutate anything at all. What you described can be achieved without redundant OOP classes and without mutating state at all! Additionally setting found to have a default value of Null negates the need for the extra accumulator parameter during function calls as you can just call it like this:

     saved_node = find_n_and_print_all_DFS(x, 5)

I would still say OOP is an anti pattern because it overall promotes adding these mutating parameters in your code even when you don't need save states or anything of that nature. In OOP, the existence of getters and setters and methods for accessing variables outside of the definition of the method itself heavily promotes this type of coding style regardless of whether or not it is needed.

The procedural style forces this additional "saved" feature to be evident as an extra parameter. If you never use that parameter it becomes obvious that the parameter is redundant while in OOP mutating external state is an intrinsic part of the style and like the OPs example you have to go through several logical leaps to see how redundant it is.

Well it's a bit of a chicken and egg problem, who started it? Customers pirating or companies adding DRM to their products?

I would wager that there's a good number of people who pirate things for the simple reason of them not wanting to pay for anything. This is the catalyst.

More like he already has a political stance on ebooks and he just used this one example to further his political agenda.

There's a reason why companies put customers through all this garbage and the reason is because I can easily pirate these books. So the story isn't as one sided as this guy makes it out to be. It's a contentious issue between customer rights of ownership and piracy.