HN user

ropman76

204 karma
Posts7
Comments93
View on HN

"Explanations exist; they have existed for all time; there is always a well-known solution to every human problem—neat, plausible, and wrong." -- H. L. Mencken I am not saying that the ideas you have listed are not without merit, however to say they will fix the 21 Century is a bit over reaching.

Happy New Year HN! 7 years ago

Absolutely true. However we also need people who do have solutions/ideas to these problems running for office even if they don’t know how to flip bits. It would be nice to see technology enabling skilled candidates rather than troll farms.

Happy New Year HN! 7 years ago

A small issue with number 5. How is an average technologist going to do any better with things like tax policy, immigration policy, energy or foreign policy than an account, lawyer or civil engineer? I wonder if we would all be better of trying to use technology to get good candidates in office that are not beholden to large agenda driven donors.

Like all things in life it depends on the team and workflow. I have my PM’s make tickets because many times I am in the middle of a different feature or bug and don’t want to have to have the mental load of remembering what the issue was. Secondly I work with very solid PM’s who document the ticket very well and it saves me time having to reproducing the issue. My team does have a lot of tickets but we make it work for us and our process flow.

I agree with this approach for software devs in any business. One of the cool things one of my employers (a manufacturing company) did was send me out for a day to a plant and have me see how everything worked. It made some of the websites I was building for our plant workers much easier when I already had a good idea of what they needed it for.

They already do. Many logistics companies have a "brokerage" area where try and get trucking companies (or truckers) to bid on loads going from x to y. I used to support software that did this. Not a fan of the software, but the people where blast to work with. In the area I worked with, it could get pretty crazy (lots of yelling across the room and the yelling at people on the phone LOL). They occasionally had less than ethical truckers holding loads hostage for more money....

I used to work at a manufacturing company. I know the company tried renting some robots for putting items on a rack and getting them off said rack. On the surface it seemed like a good idea since this job is repetitive and boring for a human. Sadly it didn’t work out. The amount of change in the parts being put on the rack proved to be a challenge for the robot and the company ended up ending the rental agreement.

After all this time the joke “Jon Skeet has already written a book about C# 5.0.

It’s currently sealed up.

In three years, Anders Hejlsberg is going to open the book to see if the language design team got it right.” still cracks me up.

One of the most frustrating things about dealing with situations like this is actually getting ahold of someone with enough experience to say where the issue is to begin with even if it’s out of the provider’s control.

I have sent a lot of log files to cloud vendor trying to find why their web hosted application was so slow (6-10 second response times on a CRM app they provided). If someone would have responded with an actual answer (your firewall is blocking traffic or try this setup etc) I could have worked with that. Instead we got nothing but stealth ticket closes and “sorry we don’t know why this is slow” responses. This article hit a nerve because you really do dance to someone else’s tune when you go to the “cloud”.

"After several years of trying to manage these issues with Kerberos, we decided to redesign the system from the ground up.." I am curious, is there anyone who went the opposite direction direction and implemented a new Kerberos library or setup?

I understand this situation applies if the “developer resource” is a direct report. However in many instances the dev may have multiple projects going on at once and there is some miscommunications on project priorities. Yes, this has happened to me and it’s why I abhor the phrase “developer resource”

The thing that I enjoyed being the solo developer most is that I got to make all of the software design choices. I set up the project the way I wanted to and code in way I felt would best to ship the product. Loved that aspect of it.

That being said I would do two things differently. 1. Be hyper about testing. If you are the only dev working on a project test,test and test more. Write good unit tests. Have your fellow co-founders test and sign off on a feature before going to prod. If you are working hard it's easy to miss the obvious. Test it all.

2. Find good ways to communicate where you are and what you are doing. Some features take longer than others. It drives non-technical people crazy (Why did this feature take an hour and this one a week?) but that is the hard fact of software dev. Use a Jira board or an email, whatever will let your co-founders know what features are where. It really saves on the annoying status update requests in person or over email that disrupt your day. Good Luck :)

I am moving in this direction after having taken a few coding challenges and not heard anything back from the company. If I am going to spend time on a coding challenge, I am expecting at least an acknowledgment that I am no longer being considered for the position. Coding challenges are a time commitment and if a company can't even be bothered to commit to at least being polite about it, then it's a clear indication of how they view employees.

There is a blog post from 2015 about an API for security and compliance motoring. https://www.microsoft.com/en-us/microsoft-365/blog/2015/04/2...

I respect that fact that CrowdStrike and others have spent the time with the api and made life a lot easier for others. As someone who has spent more time than he wanted with the Office 365 API I am a fan of people who make my life easier. That being said I am not buying the drama that these API's have been hidden.

I can understand about being suspicious of the NSA after the whole Dual_EC_DRBG fiasco. However these designs are not unknown throughout the industry (ARX having gotten some heat lately from the Keccak people). Is there some technical reasons these designs should be disallowed aside from "We don't like the NSA".

Building on that even, the most fun I have had at "networking" was listening to other developers talk about some of the problems they are working to solve in their jobs/areas of interest. Half the events I enjoy going to are partially motivated by "I wonder if so and so found away to fix x issue"

[dead] 9 years ago

I recently moved into a full stack developer role. Not because I am a rock star ninja coder, but because I am the only developer employee in the entire company. The only difference now from some of my more specialist dev roles is that I spend a lot more time researching things on Google/Stackoverflow etc. So when I hear full stack developer I can help but thinking "So you spend a lot of time on Google as well?" :)

The real issue is how much a corporation can enforce "correct" opinions among it's employees. This was an internal company forum. He expressed opinions that deviated from company policy (and from the sounds of it a lot of other employees at Google disagreed as well) and a lively debated ensued. OK that what sounds like a healthy thing to have happen and get ideas out there and agreed upon or shot down. However by firing him that sends a very clear message that any deviation from the norm will not be tolerated. That's not diversity, that is an attempt at moral conformity.

"And so if a founder can’t navigate a network into a VC firm, it is unlikely that founder has the skills to navigate the other networks required to succeed in building a company." At what point does it make more sense to use your networking skills to acquire more customers than use those same networking skills to acquire VC dollars?

As a lazy windows dev, I have seen more things go to web applications than desktop apps. One of my current work projects would be great as a desktop app. The client/ server divide in this website has added no small amount of hours keeping track of object state between the client and server. A desktop app would have made things much simpler in that regard. I am a big fan of desktop apps and have made a career developing them in .Net, but adding more hoops to jump through is not the answer in this regard.

When I had newborns if I had to take work home with me or stay late it would increase the stress on my wife to take care of the kids. So even if I was a little sleep deprived I went into work with a "I have eight hours to get this crap done" attitude that really pushed up my productivity levels. As far as skilling up there is more to developing skills than just pushing code to GitHub. I found that it's easier to read a Kindle one handed (holding a baby with the other) so I started buying books about some of the more theoretical aspects of computer science that don't always seem to go with my day to day coding job. I have had many "light bulb" moments doing that by either being reminded of things I had learned in school or learning something new about how things work.

This is a very good paper and it's disappointing that it didn't get higher on HN. That being said I disagree with some of paper's points. I don't believe that cryptographers should take on moral responsibility for how they perceive their work may or may not be used. If a malware writer uses XTS to lock up a hard drive should Dr Rogeway be morally responsible for that since he helped create the constructions for XTS? I would argue "no" because there is a moral separation between idea and implementation. We should not burden cryptographers with moral baggage that should be placed on the people who implement or set policy to implement.

That is correct. The hard part of the logistics industry is getting the integration between warehouse, trucking and operations correct. I worked as a programmer in this space and most of the time and money in this space is not going towards apps and websites (most logistics companies have that or have easy ability to get those things up and running) but integration between interested parties.

One of the things I enjoy about Aikido is that many of the techniques have "nice" and "not so nice" variations. The ikkyo technique can put an opponent on the ground with a minimal amount of pain. The nikyo technique is similar in some ways but can hurt a heck of a lot more because of the way the wrist is manipulated. I am guessing your friend(s) was illustrating that aikido has some nice ways of inducing compliance and some "not so nice" wrist breaking ways of inducing compliance.