phereford

IMO, someone’s tangible value of putting an Ape as their avatar pic on social media might be greater than that of someone being able to use a ship purchased in Star Citizen.

It’s a little crazy to me how Twitter profiles with Apes are viewed as “influencers” and “pioneers” and get treated as such. Not my cup of tea per se, but there is tangible value for some people there.

This! I prefer 80 characters so I can have two panes of code side by side or a REPL next to my code. It is near impossible to do that on a laptop if the line length is extended to 110 without a line wrap.

Point being, everyone has very different preferences and work practices. Team standards are going to be very different from team to team but standards do help reduce cognitive overhead on wondering if line lengths or other styles need to be different.

100% this. The teams that I have been a part of that have had a lasting impact on me allow for authenticity. Sure, sometimes you get a disparaging remark that can escalate. But, in my limited experience, that downside is so minuscule to the upside of having authenticity creating happiness in the workplace.

To add to this sentiment, tests also give teams confidence that is needed. It gives engineers confidence when developing new features because the test suite will break if you introduce a regression. It gives engineers confidence during deployment/CD.

While the tangible benefits of unit tests are very important, there are other intangible benefits that are equally important.

Honeypots are the best. It will filter out at least 90% of the spam (or so I have experienced everywhere I have implemented them).

Tools that have worked in the past for me: - Confluence for long lived documents - JIRA for time boxed groupings of work. - Slack for real time comm if anything arises. - "Culture" and Process Living Document

I ran a team of about 25 in the past and followed the following agile principles to help with alignment: - retrospectives - "sprints" (preference on the 3-4 week range) - Sprint Review

Alignment, while tricky, isn't all that hard so long as processes are evolving from retrospectives and you have a single source of truth for long form documentation.

What is soul crushing to you is not soul crushing to someone else. You can certainly find people who are motivated to meet new engineers and talk and spend part of their day doing that than going to a meeting of choice.

If you are leading a team of engineers, chances are you have some form of recurring check in to see how the individual is doing. In those times, it is the leaders responsibility to understand what motivates that individual and what they enjoy doing. This way, your delegation is impactful in an empowering way and not a “well thanks for unloading the stuff you don’t like”.

I prefer people to opt in to the processes that need to be handed off as that is how you get true ownership, evolution, and trust.

Most times you are correct. In this scenario, however, it seems like he started as an individual contributor and transitioned to management. When that happens, in my experience, companies want to continue to leverage the system knowledge from the individual in some form of producing technical assets.

Believe it or not, _you_ and you alone can fix this. DELEGATE! Delegate enough to get back SOME of that coding time. Block off 2 hours a day as "Free Time" or "Creative Space" a la Michael Scott from _The Office_. People will respect that.

At my prior place of employment in which I grew the team from 0 to 25 in 3 years, I eventually delegated all the stuff I did not like and empowered my team to own it. It sounds like you can do something very similar with the culture you have there.

An example: At first I loved phone screens and getting to know candidates. I refined and built that process from scratch. Once that process was up and running, it was no longer the best use of my time to be hammering the phones and scheduling screens. There was a better use of my time and someone else that REALLY enjoyed that aspect of team building stepped up. I was able to move myself to the end of the recruiting funnel which freed up 70-80% of my time allocated to that function. The opportunity cost was simply too high for the company having me screening people.

You can certainly find a way to do that as well.

If you feel like chatting more on this, my email is in my profile. Good luck and don't burn out! Your work should be just as fulfilling as your team members work.

You can see the older HN article here: https://news.ycombinator.com/item?id=17310738

Looks like they are moving their office suite of software to React.js.

I know we are talking about this in the digital realm, but this also exists in the property realm too. Imminent Domain is used be governments to acquire land, generally below its actual valution, for building of infrastructure.

I wonder if this concept will ever make it to the digital world.

It does not have complete feature parity. One of the things missing, that is important for me and the team I am on, is the ability to share screens and allow for remote control in that session. That is a Mac App only right now, at least the last time I checked.

Hmm my mistake. The blog post said Differential Equation and a classroom of 300 some students. Not many non-core classes have 300 students in them. I remember my diff eq class (18.03) being rather large (similar to 8.01, 18.01, etc etc).

While 18.03 is not core, it is a requirement for most engineering disciplines at MIT.

It is 18.03. He may have just inadvertently flipped the 0 and 3. It is 18.03 now, and was in 2002 :D.

I think it's a grey area, but I am not an accountant. The government considers it to be intagible property in some scenarios and a capital asset in others. For the most part I think the capital asset happens on the conversion to fiat due to the realizing of gains and losses. If anyone else has more knowledge here, I would love to know for certain.

https://www.irs.gov/uac/newsroom/irs-virtual-currency-guidan...

There was a podcast(1) about part of your question recently. Essentially, people are playing with "house money" as they have generated net gains from BTC and other coins. Instead of incurring a taxable event by cashing out, they might just be pouring it into ICOs.

(1): https://itunes.apple.com/us/podcast/unchained-big-ideas-from...

http://firstround.com/review/why-firing-brilliant-assholes-i...

For me, it's always been just to make sure the person isn't toxic to other employees

From some other comments I skimmed: I think it's a bonus if you have opinions on software. I want to hire people that challenge the team to grow and challenge me to grow with their differing opinions. It is very important as to how that opinion is conveyed though.

There is no one answer here as every family structure is different. Like most other comments here, my 2 (5yo, 22months) children have first dibs on my time while I am not on the clock or am not dealing with a production issue off hours. Once they go to bed (sometime between 7:30-8:30pm), I determine if I have enough in the tank for either: 1) Learning 2) Spending time with my wife (second dibs on my time).

In order to "stay relevant", I have found this to work for me: 1) During my passive commutes (every morning and afternoon), I have a solid 30 minutes of either listening to a podcast if I don't get a seat or toying around with new languages/frameworks otherwise. 2) Convince your current company that it is in their best interest to bake learning into your current job.

Obviously (2) can be quite difficult, but it starts a conversation you want to have anyway about making sure the entire team stays relevant and fresh. Most people always point to Google's innovation time as a good measure of how this should be done.

Having children has absolutely changed my priorities around and put an increasing value on my time. For me, I would much rather forgo learning the new JS flavor of the week in favor of spending as much time as possible with my growing children.

Not to derail the whole premise of this article, but Susan's book looks great! Just bought it and can't wait to start reading it.

I found my mentor through my first paid web development job. The experience is absolutely worth it. That experience happened almost 10 years ago and I still catch up with him every so often.

I have been a mentor in the past (and present) and there is immense value it brings to me and the organization I am employed by.

Depending on what you are looking to gain from the relationship, I would recommend watching some C live coding streams or finding meetups for that in your area. You could also find some LinkedIn groups and reach out for a coffee/google hangout to start the process.

I have dealt with the "negative work" conundrum myself and just wanted to give some insight from my point of view on your comment.

1) It isn't always junior level programmers causing the negative work. When it is a junior level programmer, you are 100% correct that part of the blame (or MOST of the blame) falls on the lead/senior programmer. The lead/senior failed the junior without the appropriate structure, code review, etc to make their code maintainable and "healthy". Happened to me just this year and I let down one of the junior engineers on the team in a massive way and it showed.

2) What happens in the scenario that a senior/lead person is the one creating the negative work? Adding more oversight/tighter feedback loops constrains this person and will make them worse off than not. Anyone can make the argument that this person should not be a lead or a senior, but due to any number of business alterations (organizational changes, leadership changes, culture changes, etc) it is 100% a plausible scenario. What do you do then? How do you manage this piece of the puzzle?

Scenario 2 is where I have seen the most "negative work" created without finding optimal paths for fixing the issues at hand.

Not trying to hijack this, but this entire ordeal reminds me of this Hacker News comment:

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

If your livelihood is solely invested in a singular vendor, then you absolutely need to find a contact on the inside :/.

I hope he gets it resolved.

Hahahahahaha.

Also, think of the various boot camps (General Assembly, Launch Academy, etc). Those do not teach SQL, but do teach some ORM.

I don't know if it's the norm or not, but leveraging an ORM without knowing SQL is a thing. ORMs have so many benefits (query parameterization just to name one). That and people can stay in their comfort zone language (Ruby, Python, Haskell, etc) and let the ORM do the heavy lifting instead of having to dip down into SQL.

Those that are really good with an ORM can generally go into SQL with ease.

The above is not meant to be objective, just my general observations.

Ehh. More about boosting confidence and team morale than politics. The goal was achieved, and we can yak shave during slack time if need be.

We didn't make it immutable and we didn't add an index to it. Those are our next action items to help improve the performance of it.

Honestly, instead of looking into more performance gains, I wanted the team to get a huge win and for the team to look good in front of senior management :D.

Thank you!!!!

I made a very broad assumption based on my past experiences with engineers and I apologize if I offended you.

Most engineers I have met in my career have really depended on an ORM to do all of their heavy lifting. They can write some of the most eloquent ActiveRecord queries but would be unable to create the same functionality using raw SQL.

Again, deeply sorry if I offended. It was not my intention.

4000 records with a one-to-many join (the many part capped at 240 records). The aggregations are done mostly on that join table.

In our original ruby process, it would return just that, 240 records per join and aggregate on that. Our SQL process aggregates that in a stored procedure and returns the flat 4000 records.

We really didn't want to introduce another piece of technology to this stack, hence we didn't look at R or Python or Elixir. We did consider storing all of this inside elasticsearch for a hot second but keeping things in sync at the correct times seemed sub optimal and would add a layer of complexity we were all uncomfortable with.