Estoy contratando con una compañía increíble que me da un trabajo desafiante y me brinda mucho apoyo. De vez en cuando no puedo entender por qué mi código no funciona. Programación clásica, pero me siento mal facturando el tiempo dedicado a la resolución de problemas. (A veces estoy atascado durante horas.) ¿Cobras por este tipo de "trabajo"?
¿Estás depurando tu código durante esas horas en las que estás "atascado" o estás paseando a tus perros? Ese tiempo no es facturable si está paseando a sus perros. Si, por otro lado, está depurando el código que ha escrito, esa es una parte central del proceso de programación. También lo es determinar lo que cree que debe hacer antes de escribir la primera línea de código. El tiempo dedicado a escribir líneas sobre líneas de código entregable debería representar una pequeña fracción del tiempo que se dedica a la programación.
Excepto por los problemas con los juguetes, nadie escribe un código que sea perfecto desde el principio. Una vez que pasa la etapa de prueba inicial, es probable que queden entre diez y cincuenta errores por cada mil líneas de código que haya escrito. Obtener esa tasa de defectos por debajo de un error por cada mil líneas de código es una de las razones clave por las que se han desarrollado conceptos como el desarrollo ágil y basado en pruebas.
Si usted fuera empleado de la empresa, no habría duda de que se le pague por el tiempo. Como contratista, también debe facturar por ese tiempo y tener ese conocimiento obtenido de ese trabajo seguramente lo ayudará en el futuro.
El desarrollo de software consta de tres pasos: diseño, codificación, solución de problemas. Ningún software funciona después del paso de "codificación". Dado que se le paga por desarrollar software que funcione (supongo), el cliente debe pagar los tres pasos y usted puede facturar por los tres pasos.
Si cree que sus habilidades para encontrar y solucionar problemas son demasiado bajas, hay otros sitios para hacer preguntas al respecto.
¿Cobras ocho horas completas si resuelves el problema en 2? Si no es así, entonces no deberías descontar las horas que pasas resolviendo cosas.
Programar es pensar, no escribir. Todo es parte del proceso de hacer las cosas.
Si tu acuerdo con el cliente es que te pagan por horas, entonces sí. Tu cliente te compra "como un paquete" con tus cosas en las que eres rápido (ya que ya sabes cómo no atascarte) y las cosas en las que eres lento (por ejemplo, te atascas cuando aún no conoces la solución).
Vea si la calidad del código es correcta y no demasiado alta. Si te quedas atascado en cosas que podrían haber sido fáciles, pero tomaste el camino difícil, considera si eso era necesario. (por ejemplo, no usar un algoritmo n log n en lugar de un algoritmo n ^ 2 no siempre es el fin del mundo).
Si usted o su cliente se sienten muy incómodos con esto, considere cambiar a una forma más definida de definir paquetes de trabajo y no recibir pago por hora.
Droide lacónico
dandavis
martín york