This sounds fun. I’ll give it a shot next week. My prediction - 30% food related, 20% co-workers names followed by linkedin (hoping for a picture, I can’t remember names), 20% random stuff (e.g. population of Brazil), the remainder is actually job related.
Everything I googled in a week as a professional software engineer
271–280 of 399 posts
Re: Everything I googled in a week as a professional software engineer
#272This is great but the premise seems kind of straw man. I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” Perhaps this is a reference to the interviewing process. Tests are a different thing, though. I’ve been on practical technical screens where you can google, because the test was about building a larger system, and they don’t care if you don’t remember this or that API…
> I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” I've met lots of younger devs who have varying degrees of impostor syndrome, so anecdotes like this probably help people like that feel less bad about not knowing everything.
Not just younger devs, I've been a professional coder for 24 years now and I still have imposter syndrome.
Re: Everything I googled in a week as a professional software engineer
#273Earlier quoted context omitted.
> I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” I've met lots of younger devs who have varying degrees of impostor syndrome, so anecdotes like this probably help people like that feel less bad about not knowing everything.
Not just younger devs, I've been a professional coder for 24 years now and I still have imposter syndrome.
I saw Scott Hanselman speak, and he said he has impostor syndrome. I thought to myself, great, if Hanselman has impostor syndrome, I'm not even qualified. I must be an impostor-syndrome impostor.
Re: Everything I googled in a week as a professional software engineer
#274Earlier quoted context omitted.
Googling too much is an indicator that your environment or process isn't working well. It's not a point of pride if half your job requires looking up how to use tools you don't understand. The problem is that people naturally blame themselves for not knowing everything rather than accepting that we have built monuments of trash code that nobody should be expected to understand and that therefore we should stop doing…
Ideally, I would sit down and be so familiar to the problems I'm solving, the tools I'm solving them with, and the tools so suited to solving those tasks that I can just type in my solution without having to stop to consult something on the internet. Ideally, I'd be able to have tasks that are highly specified in advance and with priorities that are stable enough that I do not have to have multiple social interruptio…
> Ideally, I would sit down and be so familiar to the problems I'm solving, the tools I'm solving them with, and the tools so suited to solving those tasks that I can just type in my solution without having to stop to consult something on the internet.
This is how you can get into Csikszentmihalyi's "flow", if you add a little cognitive work and struggle to it, so it's not just typing in the solution.
> Ideally, I'd be able to have tasks that are highly specified in advance and with priorities that are stable enough that I do not have to have multiple social interruptions per day in order to be on the correct task.
Some tasks are like that, some business opportunities are amenable to that approach, some teams work that way, and many more aren't and don't. But yes, not spinning your wheels is a prerequisite to getting maximally engaged in your work and getting good results. Sometimes that requires a lot of interruptions of the actual work, because the work is rarely well specified in advance. If it was, it probably would not be interesting because it would already have been done.
> Obviously, this is not the situation.
It could be the situation, and there is work that needs to be done in that way. In fact, this work tends to have high value, including business value, precisely because our dominant working style prevents almost all of us from achieving it. We can get closer by mastering our tools and by choosing tools that afford mastery in their use.
Re: Everything I googled in a week as a professional software engineer
#275Earlier quoted context omitted.
Googling too much is an indicator that your environment or process isn't working well. It's not a point of pride if half your job requires looking up how to use tools you don't understand. The problem is that people naturally blame themselves for not knowing everything rather than accepting that we have built monuments of trash code that nobody should be expected to understand and that therefore we should stop doing…
I don't typically have to google much but I recently attempted to update webpack/babel at work and I must have made over 100 searches of error messages in build tool packages I didn't even know existed.
Exhibit A showing why I consider these tools fundamentally broken by design.
Re: Everything I googled in a week as a professional software engineer
#276Earlier quoted context omitted.
That is the symlink target, not the ln target, which is exactly why the "target" nomenclature is confusing. Also note that not every "ln" has a "--help" or uses that help message as the output. For example, try on OS X `/bin/ln -h`.
Yes, it would be platform specific as the OSX ln command would not be the same program as the GNU coreutils ln program. For GNU ln at least I don't find it confusing at all particularly considering the only other option is LINK_NAME. I guess YMMV though and it seems kinda pointless to argue whether it is or is not confusing. Perhaps a poll could quantify it.
If "target" is used to mean two different things in the same context, it is going to confuse people! This is why naming things is hard!
Re: Everything I googled in a week as a professional software engineer
#277not exactly software engineering, but back when I worked at HostGator as a tech support rep, there was a tongue-in-cheek thing that went around that the best agent was the one who could use Google most effectively. I think that that general concept is accurate for most technical roles in general; sure, you should know what it is you're doing, but the internet acts as a memory aid device and augments our ability to store knowledge to a great degree, so being able to effectively use it obviously contributes to being a more effective employee
edit: and of course StackOverflow when I briefly worked as a perl dev there.
Re: Everything I googled in a week as a professional software engineer
#278I made a search history inspector tool -- https://prototypes.cortico.ai/search-history/ -- that processes Google Takeout files and ranks and summarizes the queries to assist me in this kinds of introspection. It's especially interesting to see which queries I've made again and again over many years.
Re: Everything I googled in a week as a professional software engineer
#279> provisional headers are shown - still at it. That "Provisional headers are shown" Chrome message drives me crazy. Some time ago, I was able to disable some flags which made it go away temporarily, but now it's showing again, presumably after Chrome made some changes. It's a problem because it means that it's not showing the real request headers. Does anyone know how to fix this for good?
I use Firefox because its dev tools don't lie to me.
I'm baffled any time someone says chrome's dev tools are better. They lie, and usually about the single most important thing I'm looking for. That is not better.
Re: Everything I googled in a week as a professional software engineer
#280Earlier quoted context omitted.
I totally understand your philosophy and you make some great suggestions, but overall there's one big flaw with whiteboard interviews: Artificial Pressure and its impact on people's ability to think clearly on the spot. I am a very methodical thinker which is why I tend to prefer work in large scale ore high-performance systems where you consider the implications of thread contention and so forth. I've designed and b…
> Obviously I was laughed at for someone who's actually had 10 years experience with c++ to forget something so basic but it happens when you are on the spot. This 100% happened to me (apart from being laughed at) only it was even more of a meltdown. Also 10 years experience and a problem I could do in my sleep. It was my first interview after a long time and it triggered performance anxiety and nervousness. The solu…
I knew when the interviewer pulled out his phone to snap a picture of only that part of the whiteboard that I didn’t get the job lol