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.
433 karma · joined March 27, 2007
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.
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.
While the tangible benefits of unit tests are very important, there are other intangible benefits that are equally important.
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.
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.
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.
Looks like they are moving their office suite of software to React.js.
I wonder if this concept will ever make it to the digital world.
While 18.03 is not core, it is a requirement for most engineering disciplines at MIT.
https://www.irs.gov/uac/newsroom/irs-virtual-currency-guidan...
(1): https://itunes.apple.com/us/podcast/unchained-big-ideas-from...
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.
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.
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.
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.
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.
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.
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.
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.
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.