hndl

It looks neat! Are you SOC2 compliant?

Hi HN -- I'm gathering some info around the challenges we're facing with transitioning to a remote work setting. I would really appreciate it if you guys could take 2 minutes out to fill out the linked survey!

Thanks in advance!

Looking for Product Manager opportunities:

Location: Austin, TX Remote: Yes Willing to relocation: No Technologies: SQL, Tableau, some JS/HTML/CSS Resume/CV: https://www.linkedin.com/in/sphurti-saraph Email: sphurti.saraph@gmail.com

Can you share some resources here (e.g., services you've used)?

right

Interesting link. I've also noticed, while wine shopping with friends, that people tend to prefer a bottle with a cork over a twisty even if the twisty was priced higher.

How does this work in the case when you're still employed at a current place and a looking to make a change?

Edit - I think you mean doing a verification after an offer is put out.

REMINDER: we're talking about something sensitive here.

The solution is that every one of you listen to a friend who is in need and empathize and say, yeah -- i'm here.

Kudos to Zach for opening up about this. I'm going through a similar shit show and I'm hoping that folks who grok it stick close and the others just sway with.

>> And the Skype app works amazingly well.

That's a first. Let the down votes begin but Skype has always sucked. I'm hoping they do a better job with Teams.

We're trying it out now (since it's included with o365) and I find it mostly usable. It has most of the things I need (group (video) calls, screen share, search, files tab etc). My biggest complaint has been the random glitches you run into every now then (repeatedly being logged out for no reason comes to mind). That and the slowness (i'll often see a lag between when I've hit return and when my message shows up in the conversation). Hope someone from Teams is reading this :).

Agree with others are (sort of) saying. If you're a 5 person team and the CEO please keep the card on your name. Then, create a accountspayable email address so you're the only member in it. Then, whenever you get a CFO on board, include him on the account -- this should be possible on the card provided -- however, the main point is that you're aware of things that go on with your account. Have some kind of process in place so there's dual approval on critical operations (txns above a certain amount, voiding transactions etc).

Interesting contrast on the vocabulary. A bit of Googling reveals a possible explanation:

>In the field of religion there are some interesting contrasts. Words such as devá have the meaning of god in the Vedas have the meaning of devil in the Avesta. Likewise some names for Vedic gods show up in the Avesta as evil spirits. This is likely due to the ancestors of the migrants to North India being a competing tribe of the tribe responsible for the creation of the Avesta.

Taken from: http://www.sjsu.edu/faculty/watkins/sanskritavestan.htm

Nice project! Kudos for sticking to the learning bit -- being motivated without external forces is harder than most people think.

Suggestion: you're getting a lot of good feedback here. Might be good to create issues on the project. You'll likely get some takers too.

Sounds like an incubator ;)

We do have Cyclomatic Complexity (https://en.wikipedia.org/wiki/Cyclomatic_complexity). I see this often enough to understand how important it is.

I was hoping to find something concrete here but found mostly fluff (and some nice quotes, sure).

I've worked with some incredible engineers so I'm going to share what I've noticed and learned over the years:

1. They write code which elegant and easy to read (cyclomatic complexity is "magically" low).

2. They know their data structures, algorithms and use them when required -- that is, when there isn't a nice, clean implementation of something, they aren't afraid of writing their own version.

3. They write unit tests. They don't shy away from creating test infrastructure even if this means a lot of work on its own. The stuff built is then easy to use by future contributors.

4. They're aware of new features and frameworks.

5. They're generally friendly and are willing to explain stuff to others.

>> "You can't buy security, but you can learn it: http://decentsecurity.com/#/introduction/"

I think that's an incorrect standpoint to take when you factor in how technologically agnostic most folks are. I would better think of it as "security is default, but you can disable it if you really, really want it that way."

Very cool -- bookmarked for future projects.

These are some great points. Given that the OP mentioned that he/she's a developer I think some additional points to consider are:

- A very biased outlook to problem solving. A lot of times I see my own boss think that the right answer (to an interview question) is the one that worked for our particular case without considering that the candidate didn't have the same constraints.

- I always like to ask 'the boss' what their idea of a good team is. Some of them will say stuff like 'A team is good when they're meeting deliverables' or 'A hardworking team' etc etc. Somehow the tone weighs in here -- you want a boss who is understanding yet not a pushover, who justifies (and thereby convinces you of) his decisions when it comes to a solving problems.

- You really want to avoid the bosses who have a desire to work long hours for no real reason. This is important because of two reasons: they don't focus on the real problems and they don't value their teammates time. A good boss wants to make sure that their team is aligned with the company goals and that everyone on the team is happy and is enjoying their time with their colleagues.

Hope that helps!

Really nice! Good luck to you guys.

I hear you. Back when I was on debian I had a small script I called apt-o ('o' for oblivious) which combined the two -- as you mention.

Right. Perhaps they can begin by rolling this out only to individuals who have verified accounts.

Thank you for this.

I've been a Tech Lead for a year now. I'm still learning but some of the things I've done which I think will help are:

1. Start by setting up the development environment and getting the software you'll be working on to run locally. Then, fix a couple of easy to medium level bug fixes as soon as possible. This is the fastest way to learn what your team is talking about.

1.5 If you don't understand something that's being said at a meeting ask, but don't hijack the meeting, make a note and talk to someone who can explain in more detail.

2. Think at a high-level -- what is the product supposed to be doing, abstract away -- some engineers will talk in code -- which you may not understand early on but interpret what they're saying at a high-level.

4. Be available and approachable to everyone on the team.

5. Understand the impact of a bug fix or a feature -- how much QA effort does it require, what is the operational impact of the work, does it break backward compatibility etc.

6. Participate in product meetings and consider designing any new features as homework so you can better discuss it with the engineering team you're leading.

Good luck!

Edit

Some DO NOTs:

1. Do not complain how bad the code base is. No one likes someone new walking in and saying that at once.

2. That said, understand what technical debt there is and address it incrementally. Don't say "we should re-write XYZ."

3. Do not suggest alternate platforms and frameworks unless is absolutely makes sense -- this is especially true if the team is big and no one knows this new framework besides you. You need your existing team to contribute to and maintain projects.

Very interesting work, p8952. Can you elaborate more on what features made btrfs a good fit for the project?

Typo: "Not only will know one know who it was but you will be hidden behind a random animal! This is our way of guarantying 100% anonymity."

I'm not sure I understand. Care to elaborate? Pointers?

How does this compare with zsh + ohmyzsh?

> var roleName = > userManager.CurrentUser == null ? null : > (userManager.CurrentUser.GetRole() == null ? null : > userManager.CurrentUser.GetRole().Name);

I ask this because I find myself preferring you only 'get' the CurrentUser once and use it as required in the following block.