# Some observations about a difficult dev experience **URL:** \ **Category:** Serverless Framework\ **Created:** [March 14, 2017, 11:47pm UTC](https://forum.serverless.com/t/some-observations-about-a-difficult-dev-experience/1489 "2017-03-14T23:47:47Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![yejodido](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/yejodido/32/516_2.png) [@yejodido](https://forum.serverless.com/u/yejodido)\ **Post date:** [March 14, 2017, 11:47pm UTC](https://forum.serverless.com/t/some-observations-about-a-difficult-dev-experience/1489/1 "2017-03-14T23:47:47Z")
Hey all, love what you’re doing and the community involved, just wanted to lend an observation that may lead a lot of new devs down a rabbit hole that may be lost on those who haven’t had to solve these problems for awhile. I believe a lot of these can be addressed through the docs. Normally this wouldn’t be too much of an issue, but searching through the issues/docs/googling actually made finding the solution _more_ confusing. ### 1. Basic Logging When I was spinning up some basic functions I threw a few `console.log`'s in and was surprised to not see output. So I went digging for the solution. The first two results from google are: [https://github.com/serverless/serverless/issues/281](https://github.com/serverless/serverless/issues/281) [https://github.com/serverless/serverless/issues/2416](https://github.com/serverless/serverless/issues/2416) The first issue basically stops at “This is what environments are for” and then devolves into a discussion on the benefits of learning JAWS. (EDIT: Just learned after some googling that JAWS was the former name of Serverless 😉) Discussion picks up about a year later about progress on a related issue. I stumbled across another issue where I noticed the user printing out via `sls logs`, so I was using that for awhile until I noticed the `local` flag on invoke which solved all my problems. After reading some issues, perhaps old, in the back of my head I was under the impression that running the functions locally was out of the question. ### Solution Emphasis the ability to debug via `sls logs` or `sls invoke local` during the onboarding experience. ### 2. CLI mentions setting “SLS\_DEBUG=\*” when functions error This is related to my past experience before solving locally. I start by googling `serverless setting environment variables` which turns up general info about setting environment variables, so I attempt to intuit the method to address this concern through the manifest and come up with: ```auto hello: handler: handler.hello environment: SLS_DEBUG: true ``` I deploy, and the function is still acting the same as before. Since the syntax between the CLI and googling about the environment variables result in two totally separate syntaxes, I google `serverless SLS_DEBUG` and get: [https://github.com/serverless/serverless/issues/1690](https://github.com/serverless/serverless/issues/1690) Which has a suggestion of using `export SLS_DEBUG=true` which is a third syntax unlike the first two. I now have no idea which of the three to use, nor where: ```auto SLS_DEBUG=* // 1 environment: SLS_DEBUG: true // 2 export SLS_DEBUG=true // or 3 ``` And unfortunately none of this is in the docs. Like I said, I was able to solve my problem by invoking locally, but I wanted to be thorough here because I find these to be pretty basic questions that I’m sure a ton of developers new to the platform will be googling, but the paper trail to getting to the proper solution is really, really hairy. ---
**Author:** ![rowanu](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/rowanu/32/75_2.png) [@rowanu](https://forum.serverless.com/u/rowanu)\ **Post date:** [March 15, 2017, 1:47am UTC](https://forum.serverless.com/t/some-observations-about-a-difficult-dev-experience/1489/2 "2017-03-15T01:47:40Z")
Logging is hard in a server-less environment. The `sls logs` command is one of the ways Serverless is trying to make it easier for developers. `sls local` is one of the other ways the framework is making it easier to get feedback quickly, but is relatively recent functionality in the grand scheme of things. Logging is definitely a problem-space with lots of room for improvement. The `SLS_DEBUG` environment parameter is for debugging the Serverless Framework, _not_ your functions (which are deployed by Serverless, but not actually running the Serverless code). You use it when you run the `serverless` (or `sls`, which is just an alias to `serverless`) command e.g. `sls deploy ...`, etc. It doesn’t have any impact in your function, unless you specifically add it. Nice work sharing your experiences! I think it’s something we all go through, we just try to forget about it… 😉 ---
**Author:** ![yejodido](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/yejodido/32/516_2.png) [@yejodido](https://forum.serverless.com/u/yejodido)\ **Post date:** [March 15, 2017, 2:00am UTC](https://forum.serverless.com/t/some-observations-about-a-difficult-dev-experience/1489/3 "2017-03-15T02:00:18Z")
Thanks for the clarity on the SLS\_DEBUG! If there’s a way to increase the transparency/path-to getting at `sls local` in the docs I think it will go a long way. Googling/searching issues led me to building out-of-date mental models about how to solve these problems, when the solution was buried in version release notes.