Digitalistas es una cuenta de Instagram y un blog personal creado por Luis Serrano, para compartir consejos y trucos acerca del mundo de la tecnología y el ámbito digital en general. No vendo productos, ni promociono servicio alguno. Lo hago de forma altruista y desinteresada, para intentar explicar conceptos técnicos y del mundillo digital a gente con dudas al respecto.

Visita la web de Digitalistas para más información, o sígueme en Instagram y en Facebook.

Reset the Bluetooth module

First, try this. It’s the most repeated answer when googling the issue, but to be honest it’s quite lame and random because it seems to work sometimes, and you won’t know if it worked before trying a few times. As I said, no help from Apple, no error/feedback messages so that forces you to really test and try and experiment. LAME. Anywhoo, let’s try it!

• While holding the Shift + Option (Alt) keys on your Mac’s keyboard, click the Bluetooth symbol in the top-right corner of the macOS menu bar.
• You’ll see a Debug item in the menu, go ahead and click it.
• Then, click Reset the Bluetooth module.
• Some people also suggest you need to restart your Mac (Windows style).

As I said, this sounds extremely lame, especially if you need to restart your machine for your Bluetooth to work again. If you ask me, restarting your machine SHOULD already reset everything, right? Anyway, try with and without restarting and see if that works for you.

The reason I gave you this “solution” first is that it only requires a few clicks (and maybe restarting your machine). If it doesn’t work for you, try the next tip.

Use blueutil

During my quest for a definitive solution that does not involve restarting my machine, I discovered a tool called blueutil. It’s basically a CLI for Bluetooth on OSX. To install it, follow these instructions:

Homebrew

# install
brew install blueutil

# update
brew update
brew upgrade blueutil

# uninstall
brew remove blueutil

MacPorts

# install
port install blueutil

# update
port selfupdate
port upgrade blueutil

# uninstall
port uninstall blueutil

From source

Only for the brave…

git clone https://github.com/toy/blueutil.git
cd blueutil

# build
make

# install/update
git pull
make install

# uninstall
make uninstall

Once installed, run this command:

blueutil -p 0 && sleep 1 && blueutil -p 1

Now, that worked for me! It basically does the same than the previous tip, but without restarting. I have created an alias for that command called fixbt, so whenever the Bluetooth module decides it’s time to f*ck with me just before an important call, I quickly run it and all goes back to normal. If it doesn’t work for you, let me know!

Note to Apple

Dear Apple. Please fix this issue, thousands of people have suffered it for years, and there is no reliable, official solution, despite the many updates we’ve installed. Also, please, in general, provide feedback to users. Errors happen, it’s ok. What’s not ok is to be confused when they happen, without knowing the reason and possible solutions. Thank you.

Photo credits: Photo by Thomas Q on Unsplash

Si has leído mi artículo El muro de la entrevista técnica, tendrás un poco de contexto respecto a lo que opino de las entrevistas como candidato. Resumiendo, si no lo has leído, creo que muchas veces el encargado de validar técnicamente a un candidato tiene visión de túnel, y se centra en el resultado de un test sin tener en cuenta nada más.

En mi opinión, es totalmente acertado tratar a un desarrollador como a un desconocido que tiene que demostrar sus conocimientos. Pero tampoco podemos arrugar el curriculum y lanzarlo a la papelera, juzgando toda su carrera y experiencia en una hora de entrevista y/o prueba técnica. Creo que hay que leerse el curriculum completo, detectar una trayectoria, una motivación y una actitud. Hay que tener en cuenta todo lo aprendido anteriormente, y la capacidad de adaptación. Si una persona ha hecho exactamente lo mismo durante toda su vida, si no ha salido de su área de confort, si no ha aprendido nada más que aquello que “le ha funcionado”, esto podría indicar que la persona es un tanto rígida, incluso cómoda. Si queremos a alguien con capacidad de aprendizaje y curiosidad, este curriculum ya nos estaría diciendo mucho. Si recibimos a alguien con experiencias variadas, que demuestran una evolución y un aprendizaje, incluyendo una especialización en un área, también tenemos un mensaje muy interesante y es esto en lo que nos tenemos que basar para decidir.

Lo que quiero decir es: no sirve un guión único para entrevistar a personas distintas, y la foto fija de lo que escuchamos en una hora es una visión muy sesgada de la persona a la que entrevistamos.

Llegado el momento de validar a alguien técnicamente, tenemos que tratar esa prueba técnica como lo que es: una fase desagradable del proceso de selección. Un momento… ¿por qué desagradable? Pues porque los programadores hemos tenido que sentarnos delante de EGOS con una visión única de cómo se hacen las cosas, o de programadores demasiado ocupados como para mostrar empatía alguna. Nos plantan un test copy & paste y, muchas veces sin siquiera saber cuáles son las condiciones del puesto de trabajo, tenemos que impresionar a esa persona. Además hoy en día muchos, muchos programadores tienen opiniones muy fuertes y arraigadas, y lo peor, distintas, de cómo implementar una solución. Y lo que no encaja en su cuadriculada visión, no sirve. Una cosa son las personas que se fijan en las buenas prácticas y los “antipatterns”, y otro tema son los opinionated developers. En mi humilde opinión, en las entrevistas técnicas abunda más lo segundo.

Por no mencionar, por ejemplo, ese puesto de Front-End developer que tiene como prueba técnica un algoritmo en Node.js para realizar una búsqueda binaria o buscar la forma más óptima de recorrer un árbol de nodos. O los que exigen TDD sí o sí. Unos piden cosas irrelevantes al puesto (sobre todo los que te piden que lo hagas en una pizarra o en papel). Otros asumen que su forma de hacer las cosas es la única, y de paso asumen que el candidato no podría aprender una nueva metodología. No hay peor arrogancia que descartar a un programador porque no tiene experiencia con nuevas metodologías, librerías o frameworks.

Sobre todo porque seguramente la persona que decide descartar aprendió eso mismo hace dos días.

Todos podemos aprender, y no hay que darle la patada a una persona que no ha tenido la oportunidad de aplicar algo en proyectos reales. Vale, también está el caso de ese candidato que no tiene ni idea de un concepto que debería al menos conocer. Pero todos sabemos que por muchos blogs que leamos, y por muchos podcasts que escuchemos, si no trabajamos con algo en proyectos de verdad, en nuestro puesto de trabajo, no llegaremos nunca al nivel de quien sí lo hace.

Como Team Lead en el pasado, fiché a gente en contra del criterio de mis Seniors. Vi el potencial, vi la actitud, sabía que si les daba la oportunidad, al menos iban a poner todo de su parte para cubrir los huecos de conocimiento. Y sabéis qué? Solo una vez me equivoqué, y fue porque dejé que la amistad con esa persona nublara mi filtro. Era mi amigo y asumí que se pondría las pilas por mí, pero no fue así. Pero son lecciones que ayudan, lo importante es no perder la fé en las personas, y sin caer en el buenismo, de verdad poner voluntad en centrarse en lo bueno de alguien, no en sus fallos. Las carencias son una cosa universal: todos las tenemos o las hemos tenido. Y todos, cuando nos han dado la oportunidad, hemos trabajado para mejorar. Yo creo que muchas veces no hay candidato malo sino entrevistador obtuso.

Como Technical Recruiter en la actualidad, dejo que Recursos Humanos haga su trabajo, su pre-filtro, que todavía es muy necesario. Y luego recibo a esas personas que aspiran al puesto, y me fijo en todo. Pero sobre todo, les doy la oportunidad de darle a la empresa lo que necesita: un buen profesional que lo dará todo en su puesto de trabajo.

Si quieres que te ayude a validar tus candidatos, no dudes en ponerte en contacto conmigo.

Para quien no lo sepa, la vida del programador es una vida privilegiada. No falta trabajo, está generalmente bien pagado, y además cada vez es más habitual que incluso nos dejen trabajar en remoto. Una libertad que pocas profesiones tienen a su alcance, la gran mayoría requiere plantarse físicamente en el mismo lugar, cada día de lunes a viernes, con un horario cerrado. Nosotros los programadores podemos optar a trabajar desde cualquier sitio y administrando nuestro tiempo, con un criterio que se reduce a “terminar mis tareas a tiempo”.

Todo esto suena muy bien y realmente me siento feliz porque las cosas son así para mi y mis colegas.

Pero no todo es felicidad, obviamente hay puntos oscuros en nuestro sector. Muchas veces hay horas extras no remuneradas, managers que no tienen ni idea de tecnología (cada vez menos, afortunadamente), ambientes de rivalidad tóxica, temporadas de presión y de no quitar la vista de una pantalla durante días, semanas e incluso meses… Son cosas que podría decirse que en cierto modo están presentes en otros sectores, pero en el nuestro es bastante común.

Ahora, ya entrando en el tema que nos ocupa, voy a hablar del punto más negro, en mi opinión. Esto es, la velocidad con la que cambian las tecnologías, las modas, y con ello, el miedo constante a quedarse obsoleto y a las pruebas de selección cada vez más duras.

Programador que buscas trabajo

Si estás buscando cambiar de trabajo, o estás desempleado y estás intentando entrar en una empresa, habrás sentido un pequeño escalofrío al leer el párrafo anterior.

Pongámonos en la situación del programador más habitual: llevas mucho tiempo en una empresa, trabajando para uno o dos proyectos o desarrollando producto. El equipo al que perteneces ha decidido usar una tecnología, bien porque se adapta al proyecto, o simplemente porque es “lo que todo el mundo está haciendo”. O sea, una de esas modas pasajeras. Angular, React, Vue… También puede que hayas entrado en la empresa y lleven tiempo usando esa tecnología, o incluso un framework propio.

El caso es que estás ahí, haciendo tu trabajo lo mejor posible, con un ojo en las nuevas tendencias, leyendo artículos técnicos, haciendo algún tutorial, y siempre comparando lo que tú y tu equipo hace con posibles alternativas. Aprendiendo siempre, cada día, mejorando, intentando crecer y aportar valor.

Pero el mundo fuera de tu trabajo cambia más rápido. Salen nuevas librerías y frameworks. Cientos, miles de artículos en Medium, LinkedIn, blogs de rockstar developers y otras populares plataformas bombardean Internet con opiniones y guías de “buenas prácticas”. Los requerimientos de estas nuevas tecnologías y la cantidad de herramientas alrededor de ellas crecen cada día. Ahora el programador de Javascript tiene que ser un experto en unit testing, end to end testing, docker, programación funcional (en especial inmutabilidad, paradigmas más populares, etc). Además, saber CSS o SASS/LESS ya no basta, ahora también CSS en JS. También temas de testing se hacen cada vez más complejos, llega el unit testing al UI, el Test Driven Development, e2e, con sus correspondientes librerías y herramientas: mocha, webdriver, selenium, jest…

Mientras, tú, en tu empresa, no usas nada de eso. Por mil motivos. Te pueden llamar poderosamente la atención, pero no consigues introducir esas tecnologías y formas de trabajar en tu día a día. Antes, esto era una simple queja: me gustaría hacer todo eso porque suena divertido y además seguro que al final redunda en más calidad y menos bugs. O sea, reducir frustraciones para ti y para tu equipo, a costa de invertir un tiempo en aprender a controlar ese creciente nuevo ecosistema.

Bueno, hoy en día ya no miramos a otras empresas que hacen todo lo nuevo y mejor con simple envidia sana. Ahora miramos con miedo. ¿Por qué? Porque el día que queramos cambiar de trabajo, o que nos quedemos en el paro, iremos probablemente a parar a una de esas empresas y nos exigirán experiencia con todo eso que no hemos tocado. Lo hemos visto en tutoriales, hemos hecho algún experimento, pero no nos hemos peleado con ello en proyectos en la vida real. No hemos configurado desde cero un entorno que incluya ese inmenso manojo de distintas herramientas, integrándolas todas juntas de forma que satisfaga al sí experimentado programador.

Ese experimentado programador que tuvo la suerte de poder aprender todo eso trabajando, en un proyecto real, y apoyado por un equipo entero. Quizá no fue suerte, quizá empujó lo suficiente para que esas tecnologías fueran adoptadas en su proyecto, en su empresa. Pero en todo caso no fue una guerra que libró él solo. Fue una decisión hecha en grupo, en equipo. Seguramente no fue fácil, no le vamos a quitar mérito. Pero ese mismo programador, que pasó por ese proceso, un día se encuentra en la posición de decidir si contratar o no a alguien que no tiene ni sus conocimientos ni su experiencia en lo que él/ella llama “buenas prácticas”. Ahora viene el mensaje para la persona en esta posición.

Programador que filtras candidatos

No me malinterpretes, toda empresa tiene absoluto derecho a decidir a quién contrata y lo que espera de un programador. Faltaría más. Quizá el equipo necesite a alguien productivo desde el primer día, y por tanto cuanto más conozca, mejor.

El peligro viene cuando se generaliza el alto nivel de exigencia, cuando una persona que ha pasado por una situación de cambio y aprendizaje, patrocinado por su equipo y empresa, asume que otro programador no está a la altura por no haber tenido la misma oportunidad. Cuando se rechaza a un candidato que no sigue los últimos paradigmas, se le está diciendo a la persona rechazada: “no creo que seas capaz de aprender”. Porque en nuestro mundo, en programación, no es cuestión de saber o no saber, es cuestión de ser capaces o no de aprender. Y después de aprender, poner en práctica.

Es bastante desolador enfrentarte a esta situación como candidato. Especialmente porque de repente, todo eso que nunca tuviste la oportunidad de hacer en un proyecto, lo tienes que aprender, tú solo, en tu casa, en tu tiempo libre, quitándole tiempo a ocio, pareja, hijos. Y tienes que aprenderlo bien, todo de golpe, ponerlo en un proyecto que sea capaz de convencer al experimentado programador que lo mirará fríamente. Y le encontrará defectos, porque su experiencia en proyectos reales, habrá depurado su técnica y será muy superior a la del candidato.

Evalua a la persona

Lo que estoy diciendo con este artículo no es que no filtremos a la gente y que dejemos pasar a todo el mundo. No. Las pruebas de selección tienen que ser exhaustivas, hay que comprobar que una persona de verdad podría encajar en un equipo a todos los niveles, técnico y personal.

Pero no seamos obtusos. Y sobre todo, no veamos la paja en ojo ajeno ignorando la viga en en propio. No olvidemos nuestra propia trayectoria, hace unos meses sabíamos menos de lo que sabemos ahora, y hemos aprendido a veces por curiosidad, otras por mejorar, y hasta quizá para cumplir con nuevos requerimientos de nuestra empresa o del mercado en general.

Yo, por hablar casos concretos que puedo poner como ejemplo, con total orgullo, he sido Lead Front-End Developer en una startup alemana que creció enormemente y hoy en día es una megaempresa. Allí, cuando entré, éramos 4 gatos en una habitación, y cuando me fui 3 años después, la empresa tenía más de 300 empleados en varias ciudades europeas. Como Team Lead, una de mis funciones era reclutar developers. Pasaban un primer filtro con Recursos Humanos, pero luego pasaban a mis manos. Les mandaba una prueba técnica y decidía si hacer una última entrevista con ellos o no.

No voy a mentir, era un coñazo. Tenía que revisar un número creciente de pruebas, compaginando con mis tareas de desarrollo, muchas veces bajo mucha presión y deadlines estrictos. Pero lo hacía, y veía cada prueba como una persona ilusionada que había pasado parte de su tiempo en intentar mostrarme sus skills. Por aquel entonces era poco lo que demostrar. HTML, CSS y Javascript en forma de jQuery y ya. Nada de Gulp, Grunt, Webpack, ni frameworks, ni tests unitarios, nada. Había gente que se lo curraba, me enviaban proyectos con una estructura limpia, comentarios, código legible, y hasta reusable. La verdad que tenía que ser un auténtico desastre para descartarlo, por ejemplo todos los archivos en la misma carpeta, código duplicado, y en general red flags comunes que hoy en día siguen vigentes.

Era exigente, pero en caso de duda, cuando el código era solo “correcto” y nada en la prueba me impresionaba, aún generalmente seguía adelante con el proceso. Le daba a la persona la oportunidad de explicarme qué cosas mejoraría, y en general un poco que me contara cómo había llegado a producir el mini-proyecto. Me interesaba la persona. Muchas veces, en contra del criterio de mis superiores, recomendé contratar a ciertas personas. Vi en ellas voluntad real de aprender, de crecer. Vi ilusión. Muchos programadores pueden saberlo todo sobre el último grito en desarrollo, pero hablas con ellos y están quemados. Yo siempre me guié por el instinto para decidirme a apostar por alguien, y el principal era ese, la ilusión. Porque la ilusión y la voluntad llevan a la persona a querer seguir aprendiendo, a disfrutar de su trabajo, a querer ser mejor. Y todo ello es contagioso y aporta un valioso factor de frescura a un equipo. En caso de ser contratada, esa persona tendrá mucho que demostrar, y un periodo de prueba que superar, que para eso está. Tengo que decir, repito, con orgullo, que elegí bien. Hoy en día, gente por la que tuve que pelear para recibir el visto bueno, son los mejores profesionales con los que he tenido el placer de trabajar. Han crecido dentro de aquella empresa, o fuera de ella, ocupando puestos de Senior y de Lead Developers.

No digo que sin mi no hubieran llegado a donde están, lo que digo es que sin mi y sin otras personas que deciden con mi mismo criterio, muchos grandes profesionales se quedarían fuera del mercado.

Yo mismo tengo 17 años de experiencia y temo las entrevistas técnicas. Muchas veces, me tratan con frialdad, no valoran mi recorrido, mi capacidad de adaptación y de aprendizaje. Acepto esto como parte del sistema, y por supuesto eso no me detendrá. Pero me gustaría lanzar este mensaje ahí fuera, por si cae en manos de las personas que filtran candidatos. El mensaje es simple:

EVALUA A LA PERSONA.

La persona, entendida como un conjunto de habilidades: sus conocimientos, su actitud, su visión, su forma de expresarse. Contratar a un crack que luego es un inadaptado o que tiene ideas muy cerradas y se niega a salir de su comfort zone, ¿de qué te sirve?

Y a los que os encontráis buscando trabajo: no os desmoralicéis. Fallar en una entrevista o ser rechazados por un review negativo de una prueba técnica es una oportunidad para aprender. Sí, seguramente es más fácil hacerlo mientras cobras un sueldo y apoyado por un equipo, y no a solas en tu casa. Pero puedes hacerlo. Toma el feedback de esas entrevistas fallidas y úsalo para aprender, para mejorar. Busca opinión de amigos o profesionales del sector, crea un proyecto que sea tu sandbox de pruebas, y depúralo hasta que pase el más exigente de los tests. Alguien será capaz de ver ese progreso, esa actitud. Y te darán la oportunidad.

No te rindas.

Si te ha gustado este artículo, por favor comparte Y si tienes problemas para encontrar talento, te sugiero mi nuevo artículo, Cómo encontrar buenos programadores

Soon, a full post with highlights of the trip

THAT is being family friendly. Any other thing is being a hypocrite. If you, big boss, neglect your own family, that’s fine, it’s your choice. But I won’t ever put ANY job, no matter how well they pay me, above my wife and son. NEVER. Because guess what, we only have one life to live, and I choose a different kind of wealth. I choose the luxury of time over expensive cars and houses. If I wanted to be rich and alone, I would probably have 3 companies, because I do have the will and knowledge to do so. But I haven’t done it because I very much prefer to spend 8 hours a day doing what I like (and you paying for that), then going home to my family.

If you don’t understand that, as I said, it’s your choice, but I don’t want to work for you. You can be my customer maybe, but I won’t trust you to be my employer, because your values suck.

PRO-tip: If you let go someone because his/her family life is not compatible with your world domination plan, at least have the guts to let them know the real reason. Don’t use cheap excuses, and please don’t blame them or “their performance”. The problem is you. Embrace your true nature, it’s the least you can do.

PS: This is a total rant, 100%. Written after working for an Spanish company, a country where sadly this problem is very common. Old school managers in Spain think a good employee is that guy sitting more hours at the office. Is he browsing Facebook, maybe? Watching porn? They don’t know, but the employee is there, long after the others are gone. And they like it. Obviously it doesn’t work like that, and my country has a lot to learn. That’s why I work for international companies with an office in Spain, so I can benefit from mature, real management.

He published a few albums with major labels, but then in 2007 he made something bold, and in my opinion, the best work of his life. He self-produced an album called “This delicate thing we’ve made”. As a follower of his work, I myself didn’t know he was working on it till it was published, and even then it took some time for me to find out there was new material. I was totally blown away by this whole album, but if I have to choose one song, this is it: “Step into the light”. There’s something magic about it, poignant, deep… It’s not necessarily the lyrics, although maybe that too. It’s the whole composition, the vibe, Darren’s voice, a bit of everything. It’s not the deepest track in the album at all, but the song really lingered on me and I still have it on my playlist.

The album didn’t do too well, unfortunately, and there were comparisons with Madonna or Kate Bush. Who cares, I loved it! And I loved it even more after reading the journey to create it (read the story here), and the old vintage hardware/software used to produce it.

Anyway, here it is, my favourite piece. Let me know what you think!

Oh yeah!